Editing record, verbose view

The Edit-Viewing Window is the primary dialog used in the tool. Here the data record content can be examined or changed as needed.  Data stewards and standards creators spend most of their time here refining the data concepts for each record in the standard.  Data Users and Deployments use this page to quickly determine relevant information about the entry.

This dialog is rather complex, and here it is broken up into two major sections. The previous section dealt with the controls that are displayed in the terse mode. This section deals with the verbose mode as some additional controls are also presented.

Continuing with the controls displayed in the VERBOSE mode...

The descriptions of these fields are brief due in part to different usage interpretations.  Very little discussion regarding their proper use is provided, unlike other pages of this document where we have gone to great lengths to teach the proper conventions of ITS practice.  That is simply because people can not agree on what many of these items are for, or how to properly fill them out.  This author is reluctant to use the opportunity of the Mini-Edit help manual as a bully pulpit to express his own views in this area.  It is perhaps sufficient to state that you can build a complete and correct ITS deployment without many of the items displayed on this page.

Terse button The button toggles between the Terse and Verbose modes of display. In the terse mode, fewer controls are displayed than in the verbose mode. The verbose mode displays more controls and they are described here. [Top]

Record Type The fundamental type of record is displayed here in a drop-down list. Background: All records are internally structured the same, but different business rules are applied as needed. Some additional record types defined in the IEEE 1488/89 are supported here but have never found widespread use in ITS, nor is there any real agreement on what they are for or how they are filled in. The following basic record types are well developed and in use in ITS, and the SDO FADDs are made up almost entirely of these four types: Data Element      A simple structure made up of a single primitive element (integer, string, etc.) which forms part of a data dictionary and which may be used in (inside) data frames and other structures consisting of valid ASN and XML (as a type, not as an element). Data Frame     A complex structure made up of a combination of primitive elements (int, string, etc.) and/or other complex structures which forms part of a data dictionary and which may be used in data frame and other structures. Consisting of valid ASN and XML (as a type, not as an element). Message     A complex structure made up of a combination of primitive elements (int, string, etc.) and/or other complex structures which forms part of a data dictionary and which may be used in data frame and other structures. This complex structure can be exchanged between parties to effect a functional requirement. Consisting of valid ASN and XML (both an element and a type). Dialog  A mapping to one or more messages in a service endpoint performing some form of operation, typically expressed in WSDL.   Key concept:  Any single record (found in a table, which is in a file) can be any one of these types. This has nothing to do with the ASN or XML found in that record.  Ideally they should match (i.e. one would expect to find simple definitions of data elements in a record marked as a data element type rather than complex messages) but they do not have to be so.  Ill formed records, particularly when a standard is being developed and changed, can be common.  [Top]

Alt Name The Alterative Name contains the synonymous descriptive name for the entry. Some SDOs have used this field to keep older descriptive names when they are changed as a nod to backwards capability. [Top]

Source The Source is the full and complete official name and revision of the standard from which the record comes. The table Source in the MEdit_Settings.mdb file contains a list of all known files, which is used to populate this field.   This table also contains the mappings of these strings to the Module-Fadd mapping for that standard.  To determine what FADD a record belongs to, its source string is matched to this table and the FADD value found is used.  If a string is used which does not appear in this table, it will be mapped to the UNKNOWN FADD when it is exported or other records will not be able to link to it when they re-use it in their ASN. [Top]

Keywords The Keyword is a list of possible search keywords that people have used from different value domains over the years. [Top]

Units The Units is a list of possible units that people have used from different value domains over the years. Interpretation of IEEE 1488/89 and ISO 14817 is a bit vague here. The table Units in the MEdit_Settings.mdb file contains a list of all known valid units which are used to populate this field. This file is generally applied only to data element records, but there is no firm rule on this. [Top]

Ref Value Domain The Ref Value Domain is a list of possible referencing systems that people have used over the years. Interpretation of IEEE 1488/89 is a bit vague here.  The table RefValueDomain in the MEdit_Settings.mdb file contains a list of all known valid units which is used to populate this field. [Top]

Formula The Formula field of the record is displayed here. The textual entry area of the control is a rich text control; when it is active, a rich text editor is displayed. [Top]

Harmonization Notes The Harmonization Notes field of the record is displayed here. The textual entry area of the control is a rich text control; when it is active, a rich text editor is displayed. This is an area we were developing when SAE funding support for the tool was cut off. Its intended purpose was to allow the automatic collection of feedback from other people commenting on your data record (very useful for data stewards and for committee balloting comment use). It is maintained today because some people still use it as a handy scratch pad file in the record. [Top]

Desc Name Context The Descriptive Name Context is a list of possible categories for names that people have used from different value domains over the years. Interpretation of IEEE 1488/89 is a bit vague here. The table Descriptive_Name_Context in the MEdit_Settings.mdb file contains a list of all known valid values which is used to populate this field. The entry Traffic Management is often chosen as the most general term. [Top]

Class Name The Class Name is a list of possible categories for names that people have used from different value domains over the years. Interpretation of IEEE 1488/89 is a bit vague here. The table Classification_Scheme_Items in the MEdit_Settings.mdb file contains a list of all known valid values which is used to populate this field. The entry Traffic Management is often chosen as the most general term. [Top]

Configuration System The Configuration Systems allows picking from a list of registry systems that are being used as the baseline for this record. There are only four possible categories for names here (1488 or 14817 choices). The table Config_Baseline in the MEdit_Settings.mdb file contains a list of all known valid values which is used to populate this field. [Top]

Object ID The Object ID (OID) field of the record is displayed here. This is an open string because different groups have different formatting they use when creating this value. In general you will see this used in the NTCIP standard when MIBs matter, and not in the message (ASN or XML based) efforts. However, IEEE 1488/89 states that it must be filled out, so a value of 0000 is often used to mean none in practice. [Top]

User The User field is an open field not used by any SDOs at this time. See the remarks for the View field. [Top]

View The View field is an open field not used by any SDOs at this time. Both the View and the User fields are an ill-conceived attempt in IEEE 1488/89 to register what deployment or end users of a registry system might have interest in a certain record.  There was also some failed attempts at managing MIB content relationships using this field   This blunder is repeated in the ISO 14817 as well. The fundamental design need is real: that of knowing which users care about what records. But its attempt to solve this by adding burdensome meta-data to the authoritative record (rather than binding it in the register design, typically in an associated table generated on demand) is the problem.   Use the Linking Report function to achieve this ability. [Top]