# DEs

DEFINITION:
This is the definition of an item defined locally.  The simple case of an atomic data element which is then used in the message and data frame found in the same standard.  Most of the data registry is made up of this type of entry.

REMARKS:
When used by the SDO in its own module you say:  myCat ::= Cat   and then need to provide the def in your own module.  But when used by others you say:  myCat ::= XXXX.Cat   where XXX is what ever module it came from  - and then need to provide the def in another module.

XML-SCHEMA:
<xs:simpleType name="Cat" >
      <xs:restriction base="xs:unsignedByte">
         <xs:minInclusive value="1"/>
         <xs:maxInclusive value="10"/>
      </xs:restriction>
</xs:simpleType>


DEFINITION:
Date for which a directory entry or other use is being requested by a Traveler - primarily effects event information returned. The precise time at which this date starts may vary with the time zone of the service.  For example; Saturday stay over rates for an airline begin at the point of departure.

VALID-VALUE-RULE:
(SIZE(8))
-- format as: YYYYMMDD where 
-- YYYY  the year, in common era units
-- MM  the month, range 01 to 12
-- DD the day, range 01 to 31
-- use zero for MM and DD when not applicable

KEYWORD:
Directory, Search Request, Radius, Search,Proximity

XML-SCHEMA:
<xs:simpleType name="Date" >
      <xs:annotation>
         <xs:documentation>       
            format as: YYYYMMDD where
            YYYY  the year,  in common era units
            MM  the month,  range 01 to 12
            DD the day,  range 01 to 31
            use zero for MM and DD when not applicable
         </xs:documentation>
      </xs:annotation>
      <xs:restriction base="xs:string">
         <xs:length value="8"/>
      </xs:restriction>
</xs:simpleType>


DEFINITION:
Time for which a directory entry is being requested by a Traveler - primarily affects event information returned.

VALID-VALUE-RULE:
(SIZE(6..10))
-- Format:  HHMMSSssss
-- Valid times using 24 hour notation.  
-- HH=00 through 23; MM=00 through 59; 
-- SS=00 through 59; 00 if NA
-- ssss=0000 through 9999. 
-- Use SS= 60 for leap seconds
-- HH represents hours, MM minutes, SS seconds, 
-- and ssss decimal seconds to whatever number 
-- of significant digits is required (up to four)

XML-SCHEMA:
<xs:simpleType name="Time" >
      <xs:annotation>
         <xs:documentation>       
            Format:  HHMMSSssss
            Valid times using 24 hour notation.
            HH=00 through 23; MM=00 through 59;
            SS=00 through 59; 00 if NA
            ssss=0000 through 9999.
            Use SS= 60 for leap seconds
            HH represents hours,  MM minutes,  SS seconds,
            and ssss decimal seconds to whatever number
            of significant digits is required  (up to four)
         </xs:documentation>
      </xs:annotation>
      <xs:restriction base="xs:string">
         <xs:minLength value="6"/>
         <xs:maxLength value="10"/>
      </xs:restriction>
</xs:simpleType>


DEFINITION:
Time zone, or offset, for a local time from GMT. Note that not all time offsets are in units of even hours.

VALID-VALUE-RULE:
(SIZE(4))
-- Valid time offset using 24 hour notation.  
-- HH=00 through 23; MM=00 through 59;

XML-SCHEMA:
<xs:simpleType name="TimeOffset" >
      <xs:annotation>
         <xs:documentation>       
            Valid time offset using 24 hour notation.
            HH=00 through 23; MM=00 through 59;
         </xs:documentation>
      </xs:annotation>
      <xs:restriction base="xs:string">
         <xs:length value="4"/>
      </xs:restriction>
</xs:simpleType>


# ExternalDEs

DEFINITION:
This is the definition of an item, from an external SDOs work, simply re-used here.  Note that the SOURCE field determines what SDO and document if comes from and that this entry is used to map to a set of modules into which it is placed.  
Here we chose to use TCIP as the example source.

REMARKS:
When used by the SDO in its own module you say:  myCat ::= Cat   and then need to provide the def in your own module.
But when used by others you say:  myCat ::=  TCIP.Cat   and then need to provide the def in another module.

SOURCE:
Adopted ITE TCIP, Transit Communications Interface Profiles

XML-SCHEMA:
<xs:simpleType name="Cat" >
      <xs:restriction base="xs:unsignedByte">
         <xs:minInclusive value="1"/>
         <xs:maxInclusive value="10"/>
      </xs:restriction>
</xs:simpleType>


DEFINITION:
This is the definition of an item, from an external SDOs work, simply re-used here.  Note that the SOURCE field determines what SDO and document if comes from and that this entry is used to map to a set of modules into which it is placed.  
Here we chose to use TMDD as the example source.

REMARKS:
When used by the SDO in its own module you say:  myCat ::= Cat   and then need to provide the def in your own module.
But when used by others you say:  myCat ::=  TMDD.Cat   and then need to provide the def in another module.


DEFINITION:
External data element taken from TMDD which is in turn taken from the ITIS codes.  A description of the general top level category which the event is.

XML-SCHEMA:
<xs:simpleType name="Incident-Type" >
      <xs:annotation>
         <xs:appinfo>
            accident (513) -- Use when no further data is available regarding involved vehicle type
            serious accident (514)
            injury accident (515)
            minor accident (516)
            multi vehicle accident (517) -- To be used when events are NOT distributed along a road segment (i.e. one location)
            numerous accidents (518) -- To be used when events are distributed along a road segment
            accident involving a bicycle (519)
            accident involving a bus (520)
            accident involving a motorcycle (521)
            accident involving a pedestrian (522)
            accident involving a train (523)
            accident involving a truck (524)
            accident involving hazardous materials (525)
earlier accident (526) -- Hint: Typically used as a cause, "Due to"
            medical emergency (527)
            secondary accident (528)
            rescue and recovery work in progress (529)
            accident investigation work (530)
            incident (531) -- Hint: For non-accident incidents (disabled, jackknife, etc.) where no further information is available
            stalled vehicle (532)
            abandoned vehicle (533)
            disabled vehicle (534)
            disabled truck (535)
            disabled semi-trailer (536) -- Alternative Rendering:  disabled tractor-trailer
            disabled bus (537)
            disabled train (538)
            vehicle spun out (539)
            vehicle on fire (540)
            vehicle in water (541)
            vehicles slowing to look at accident (542) -- Alternative Rendering:  On-looker slowdown, Rubbernecking
            jackknifed semi trailer (543) -- Alternatives can use: jackknifed tractor-trailer, jackknifed truck, jackknifed big-rig
            jackknifed trailer home (544)
jackknifed trailer (545) -- Hint: Used for smaller trailers (i.e. not type "jackknifed semi trailer" above)
            spillage occurring from moving vehicle (546)
            acid spill (547)
            chemical spill (548)
            fuel spill (549)
            hazardous materials spill (550) -- Also use the Disaster lists for large HAZMAT events
            oil spill (551)
            spilled load (552)
            toxic spill (553)
            overturned vehicle (554) -- Use when no further data is available regarding involved vehicle types
            overturned truck (555)
            overturned semi-trailer (556)
            overturned bus (557)
            derailed train (558)
            stuck vehicle (559) -- It is preferred to provide data which denotes WHY the vehicle is stuck (I.e. mud/snow, under bridge, too wide, etc.)
            truck stuck under bridge (560) -- Alternative Rendering:  high load hit involving truck
            bus stuck under bridge (561) -- Alternative Rendering:  high load hit involving bus
            accident cleared (638)
            incident cleared (639)
         </xs:appinfo>
      </xs:annotation>
      <xs:union>
         <xs:simpleType>
            <xs:restriction base="xs:unsignedInt">
               <xs:minInclusive value="512"/>
               <xs:maxInclusive value="767"/>
            </xs:restriction>
         </xs:simpleType>
         <xs:simpleType>
            <xs:restriction base="xs:string">
               <xs:enumeration value="accident"/>
               <xs:enumeration value="serious accident"/>
               <xs:enumeration value="injury accident"/>
               <xs:enumeration value="minor accident"/>
               <xs:enumeration value="multi vehicle accident"/>
               <xs:enumeration value="numerous accidents"/>
               <xs:enumeration value="accident involving a bicycle"/>
               <xs:enumeration value="accident involving a bus"/>
               <xs:enumeration value="accident involving a motorcycle"/>
               <xs:enumeration value="accident involving a pedestrian"/>
               <xs:enumeration value="accident involving a train"/>
               <xs:enumeration value="accident involving a truck"/>
               <xs:enumeration value="accident involving hazardous materials"/>
               <xs:enumeration value="earlier accident"/>
               <xs:enumeration value="medical emergency"/>
               <xs:enumeration value="secondary accident"/>
               <xs:enumeration value="rescue and recovery work in progress"/>
               <xs:enumeration value="accident investigation work"/>
               <xs:enumeration value="incident"/>
               <xs:enumeration value="stalled vehicle"/>
               <xs:enumeration value="abandoned vehicle"/>
               <xs:enumeration value="disabled vehicle"/>
               <xs:enumeration value="disabled truck"/>
               <xs:enumeration value="disabled semi-trailer"/>
               <xs:enumeration value="disabled bus"/>
               <xs:enumeration value="disabled train"/>
               <xs:enumeration value="vehicle spun out"/>
               <xs:enumeration value="vehicle on fire"/>
               <xs:enumeration value="vehicle in water"/>
               <xs:enumeration value="vehicles slowing to look at accident"/>
               <xs:enumeration value="jackknifed semi trailer"/>
               <xs:enumeration value="jackknifed trailer home"/>
               <xs:enumeration value="jackknifed trailer"/>
               <xs:enumeration value="spillage occurring from moving vehicle"/>
               <xs:enumeration value="acid spill"/>
               <xs:enumeration value="chemical spill"/>
               <xs:enumeration value="fuel spill"/>
               <xs:enumeration value="hazardous materials spill"/>
               <xs:enumeration value="oil spill"/>
               <xs:enumeration value="spilled load"/>
               <xs:enumeration value="toxic spill"/>
               <xs:enumeration value="overturned vehicle"/>
               <xs:enumeration value="overturned truck"/>
               <xs:enumeration value="overturned semi-trailer"/>
               <xs:enumeration value="overturned bus"/>
               <xs:enumeration value="derailed train"/>
               <xs:enumeration value="stuck vehicle"/>
               <xs:enumeration value="truck stuck under bridge"/>
               <xs:enumeration value="bus stuck under bridge"/>
               <xs:enumeration value="accident cleared"/>
               <xs:enumeration value="incident cleared"/>
            </xs:restriction>
         </xs:simpleType >
      </xs:union>
</xs:simpleType>


DEFINITION:
External data element taken from TMDD.  The abnormal surface conditions currently found on the Link (e.g., dry, wet, ice, snow, etc.).  This is taken from a sub range of ITIS codes called "Pavement Conditions".

REMARKS:
Observe that the original TMDD definition of this code set was somewhat different and that the ITIS harmonization process both added new codes and placed some other codes into other categories (such as moving "power lines down" into obstructions).

XML-SCHEMA:
<xs:simpleType name="Link-SurfaceCondition" >
      <xs:annotation>
         <xs:appinfo>
            impassable (5889)
            almost impassable (5890)
            passable with care (5891)
            passable (5892)
            surface water hazard (5893)
            danger of hydroplaning (5894)
            wet pavement (5895)
            treated pavement (5896) -- Alternative Rendering:  chemical wet
            slippery (5897)
            mud on roadway (5898)
            leaves on roadway (5899)
            loose sand on roadway (5900)
            loose gravel (5901)
            fuel on roadway (5902)
            oil on roadway (5903)
            road surface in poor condition (5904)
            melting tar (5905)
            ice (5906)
            icy patches (5907)
            black ice (5908)
            ice pellets on roadway (5909)
            ice build up (5910)
            freezing rain (5911)
            wet and icy roads (5912)
            melting snow (5913)
            slush (5914)
            frozen slush (5915)
            snow on roadway (5916)
            packed snow (5917)
            packed snow patches (5918)
            plowed snow (5919)
            wet snow (5920)
            fresh snow (5921)
            powder snow (5922)
            granular snow (5923)
            frozen snow (5924)
            crusted snow (5925)
            deep snow (5926)
            snow drifts (5927)
            drifting snow (5928)
            expected snow accumulation (5929)
            current snow accumulation (5930)
            dry pavement (6011)
            snow cleared (6012)
            pavement conditions improved (6013)
            skid hazard reduced (6014)
            pavement conditions cleared (6015)
         </xs:appinfo>
      </xs:annotation>
      <xs:union>
         <xs:simpleType>
            <xs:restriction base="xs:unsignedInt">
               <xs:minInclusive value="5888"/>
               <xs:maxInclusive value="6143"/>
            </xs:restriction>
         </xs:simpleType>
         <xs:simpleType>
            <xs:restriction base="xs:string">
               <xs:enumeration value="impassable"/>
               <xs:enumeration value="almost impassable"/>
               <xs:enumeration value="passable with care"/>
               <xs:enumeration value="passable"/>
               <xs:enumeration value="surface water hazard"/>
               <xs:enumeration value="danger of hydroplaning"/>
               <xs:enumeration value="wet pavement"/>
               <xs:enumeration value="treated pavement"/>
               <xs:enumeration value="slippery"/>
               <xs:enumeration value="mud on roadway"/>
               <xs:enumeration value="leaves on roadway"/>
               <xs:enumeration value="loose sand on roadway"/>
               <xs:enumeration value="loose gravel"/>
               <xs:enumeration value="fuel on roadway"/>
               <xs:enumeration value="oil on roadway"/>
               <xs:enumeration value="road surface in poor condition"/>
               <xs:enumeration value="melting tar"/>
               <xs:enumeration value="ice"/>
               <xs:enumeration value="icy patches"/>
               <xs:enumeration value="black ice"/>
               <xs:enumeration value="ice pellets on roadway"/>
               <xs:enumeration value="ice build up"/>
               <xs:enumeration value="freezing rain"/>
               <xs:enumeration value="wet and icy roads"/>
               <xs:enumeration value="melting snow"/>
               <xs:enumeration value="slush"/>
               <xs:enumeration value="frozen slush"/>
               <xs:enumeration value="snow on roadway"/>
               <xs:enumeration value="packed snow"/>
               <xs:enumeration value="packed snow patches"/>
               <xs:enumeration value="plowed snow"/>
               <xs:enumeration value="wet snow"/>
               <xs:enumeration value="fresh snow"/>
               <xs:enumeration value="powder snow"/>
               <xs:enumeration value="granular snow"/>
               <xs:enumeration value="frozen snow"/>
               <xs:enumeration value="crusted snow"/>
               <xs:enumeration value="deep snow"/>
               <xs:enumeration value="snow drifts"/>
               <xs:enumeration value="drifting snow"/>
               <xs:enumeration value="expected snow accumulation"/>
               <xs:enumeration value="current snow accumulation"/>
               <xs:enumeration value="dry pavement"/>
               <xs:enumeration value="snow cleared"/>
               <xs:enumeration value="pavement conditions improved"/>
               <xs:enumeration value="skid hazard reduced"/>
               <xs:enumeration value="pavement conditions cleared"/>
            </xs:restriction>
         </xs:simpleType >
      </xs:union>
</xs:simpleType>


SOURCE:
Adopted SAE J2540-2  (ITIS Phrases), March 2002

XML-SCHEMA:
<xs:simpleType name="ITIScodes" >
      <xs:restriction base="xs:unsignedShort"/>
</xs:simpleType>


# MSGs

DEFINITION:
This is an example of a data frame that uses elements both from its own standard and from others.  This is typical of the re-use of work between SDOs now being done.  
It uses the name of the ASN.1 module in which the other parts of the ASN.1 are found in front of each instance of the re-used external item.  The names chosen here are purposefully dumb, that is they re-use the same name ("cat") each instance to show that that combination of the module and the name taken together is what needs to be unique.

MESSAGE-BODY:
SEQUENCE  {
        myCat  Cat,       -- from this same local module
        catA   TMDD.Cat,  -- from another module called TMDD
        catB   TCIP.Cat,  -- from another module called TCIP
        ...
        }

REMARKS:
Not shown in this example is how the meta process of the registry can ties these elements (this element and the three others is in turn uses) together.  This is relatively easy, and very precise if we are willing to delve into the ASN.1 and parse it out.  Otherwise some additional combination of steps to link the correct pieces will be needed and it is vitally important that this not be labor intensive and thereby allow introducing errors.

XML-SCHEMA:
<xs:complexType name="MyNewThing" >
      <xs:sequence>
         <xs:element name="myCat" type="Cat" />
         <xs:element name="catA" type="tmdd:Cat" />
         <xs:element name="catB" type="tcip:Cat" />
      </xs:sequence>
</xs:complexType>


DEFINITION:
This is an example of a data frame that uses only those elements defined locally to the same standard.   [All the first generation ITS work by each SDO used only this format]

MESSAGE-BODY:
SEQUENCE {
     date    Date,
     time    Time,
     offset  TimeOffset OPTIONAL
     }

REMARKS:
Note that is this structured was to be reused in another standard (and thus appear in another module) it would have to be edited to add the module names for the elements which were once local but which would now be external from the point of view of the other using standard.  Therefore it can not be re-used as is but need to be edited to add the module name.  Lines like "date  Date"  would become "date  ATIS.Date"  when re-used.   This need to change things in order to re-use them is not desirable as it creates needless work and allows the introduction of more errors.  Several ways to overcome this need to be discussed in the CCC, among them are moving re-used things to the common data dictionary, developing automated changing methods, and other ideas.

XML-SCHEMA:
<xs:complexType name="DateTimePair" >
      <xs:sequence>
         <xs:element name="date" type="Date" />
         <xs:element name="time" type="Time" />
         <xs:element name="offset" type="TimeOffset"  minOccurs="0"/>
      </xs:sequence>
</xs:complexType>


DEFINITION:
This is an example of a data frame that is made up of two elements defined elsewhere (TMDD in this case) and those elements are in turned defined elsewhere still (from ITIS codes).  This process can go on indefinitely and the only rule for "correctness" is that is all fully resolve into defined elements at the "bottom" of the process.  And of course one element may in fact be defined as many other underlying elements, the example below is trivial in this regard.

MESSAGE-BODY:
SEQUENCE  {
   baseType       TMDD.Incident-Type,
   linkConditoin  TMDD.Link-SurfaceCondition,
   ...
   }

REMARKS:
The issues to be discussed in regards to this example are again how we document more about the linkages outside the ASN.1 realm (using the registry meta process), what we document (the first link in the chain, or the last one, or every step in between).  How this is done is very important!  It must be done in a way such that the data base integrity is maintained.  That is; changes in one place must ripple over to other places that use it and not rely on human intervention for the integrity process.

XML-SCHEMA:
<xs:complexType name="RecursiveExample" >
      <xs:sequence>
         <xs:element name="baseType" type="tmdd:Incident-Type" />
         <xs:element name="linkConditoin" type="tmdd:Link-SurfaceCondition" />
      </xs:sequence>
</xs:complexType>


DEFINITION:
This is a top level message which is in turn made up of three other complex parts (each of which is also defined here).  Note that as a "message" this entry becomes a real element in XML (rather than an abstract type).  Note that in order to build and use this message you would need to be able to collect and use all the underlying parts.  In this example all the first level parts come from the same module, but this need not be the case.

MESSAGE-BODY:
SEQUENCE  {
   thething   MyNewThing,
   theMoment  DateTimePair      OPTIONAL,
   theLink    RecursiveExample  OPTIONAL,
   ...
   }

XML-SCHEMA:
<xs:element name="CompleteMessage" type="CompleteMessage"/>
<xs:complexType name="CompleteMessage" >
      <xs:sequence>
         <xs:element name="thething" type="MyNewThing" />
         <xs:element name="theMoment" type="DateTimePair"  minOccurs="0"/>
         <xs:element name="theLink" type="RecursiveExample"  minOccurs="0"/>
      </xs:sequence>
</xs:complexType>


DEFINITION:
This example shows both the correct and incorrect use of a module name in the ASN.1 sections.  The first element item is used without a module (the typical way things were done before module use).  The second item uses a module name  (in this case "ITIS.")  The remaining items are simply to show further examples of the typical re-use of a local type def. 
Using this entry to check the syntax or export the source file for further development is a two step process.  First, the entry (along with other entries) is exported from Mini-Edit and placed into an ordering based on the modules it belongs to.  The mapping to modules is controlled by the "source" table in the control file.  Every known ITS standard has an entry and is mapped to a module (which you can edit if needed).  Unknown entries (of which there are many in the registry) are mapped to an "UNKOWN" module for further editing.   Once the output file if produced (in either ASN.1 or XML) you then take this file to the complier you use and submit it using that vendors process.  Note the Mini-Edit is NOT a syntax validation tool nor does it resolve linkage between entries, the commercial complier you use for ASN and/or XML does this.  All Min-Edit does is implement the ASN to XML rules and provide the output ordering required.  
Considering this example further...
When the first item is processed by the ASN complier it expects to find and resolve the first reference to an item called "ITIScodes" in the local current module.   When the second item is process, the ASN.1 complier expects to find a module called "ITIS." and within in an item called "ITIScodes" to which it will resolve the second reference.  In a like manor the item "SomeLocalTypeDef" is also expected to be found in the local module. Failure to find such items will result in an error message being issued by your ASN.1 compiler tool. 
In the XML translation the rules are very similar, expect that occurrences of the phrase "ITIS.ITIScodes" are processed by the XML exporter to be mapped to the selected range of enumerations.  The enumeration range is then expanded based in the ITIS db file you loaded A(which is normally the nations standard but also can be edit for local use as needed)  The listing of XML below shows this.  Note that element "itemA" has only a range restriction (all these items are presumed to exist by this method.  Your XML checker will confirm this). Element "itemB" has been fully expanded to form an in-line definition and shows a number of enumerations.  Note that the ASN.1 comment lines have been append at the end of the entry in keeping with the recommendations of the conversion rules. Element "itemC" is reflected in the local namespace. Element "itemD" has both a namespace pre-pended (in this case "tmdd:" and a range restriction.  The final two elements ("itemE" and "itemF") show the XML when a range restrcition in the ASN.1 must be passed along.

MESSAGE-BODY:
SEQUENCE  {                        
     itemA  ITIScodes (256..260),      -- should fail to expand
     itemB  ITIS.ITIScodes (256..260), -- should expand
     itemC  SomeLocalTypeDef,     
     itemD  TMDD.AnotherTypeDef,
     itemE  SomeLocalTypeDef (10..20),     
     itemF  TMDD.AnotherTypeDef (30..40)
     }

REMARKS:
From J2313, Section 7.21 Message Type:Acknowledge Data

XML-SCHEMA:
<xs:complexType name="AAA_JunkMsg" >
      <xs:sequence>
         <xs:element name="itemA" >
            <xs:simpleType> 
               <xs:restriction base ="ITIScodes">
                  <xs:minInclusive value="256"/>
                  <xs:maxInclusive value="260"/>
               </xs:restriction>
            </xs:simpleType> 
         </xs:element>
         <xs:element name="itemB" >
            <xs:simpleType> 
               <xs:annotation>
                  <xs:appinfo>
                     stopped traffic (257)
                     stop and go traffic (258)
                     slow traffic (259)
                     heavy traffic (260)
                  </xs:appinfo>
               </xs:annotation>
               <xs:union>
                  <xs:simpleType>
                     <xs:restriction base="xs:unsignedInt">
                        <xs:minInclusive value="256"/>
                        <xs:maxInclusive value="260"/>
                     </xs:restriction>
                  </xs:simpleType>
                  <xs:simpleType>
                     <xs:restriction base="xs:string">
                        <xs:enumeration value="stopped traffic"/>
                        <xs:enumeration value="stop and go traffic"/>
                        <xs:enumeration value="slow traffic"/>
                        <xs:enumeration value="heavy traffic"/>
                     </xs:restriction>
                  </xs:simpleType >
               </xs:union>
            </xs:simpleType> 
         </xs:element>
         <xs:element name="itemC" type="SomeLocalTypeDef" />
         <xs:element name="itemD" type="tmdd:AnotherTypeDef" />
         <xs:element name="itemE" >
            <xs:simpleType> 
               <xs:restriction base ="SomeLocalTypeDef">
                  <xs:minInclusive value="10"/>
                  <xs:maxInclusive value="20"/>
               </xs:restriction>
            </xs:simpleType> 
         </xs:element>
         <xs:element name="itemF" >
            <xs:simpleType> 
               <xs:restriction base ="tmdd:AnotherTypeDef">
                  <xs:minInclusive value="30"/>
                  <xs:maxInclusive value="40"/>
               </xs:restriction>
            </xs:simpleType> 
         </xs:element>
      </xs:sequence>
</xs:complexType>


# MiscText

text:
For the purposes of this standard, the following definitions, abbreviations and acronyms apply.  To be supplied….


text:
Examples of Code Reuse in the Data Registry


text:
Registry data reuse between standard developed by multiple different committees within multiple SDOs is shown with working examples and the process and method to be adopted as a best practice is discussed.   Descriptive naming recommendations are made as well as how to properly encode ASN.1 and XML entries both for re-use and to re use the work of others.  The points of coordination with the Mini-Edit tool to ensure that complete outputs can be created without introducing manual errors is also discussed.


text:
Just how do you go about re-using the entries of other standard for your own work in the registry?  How do you then get good ASN.1 and XML when you are done?  How, exactly, do you "point" to another groups work and document you intentions?  This document attempts to answer this be way of a simple but fully working example of cross data re-use.  The actual examples used, in and fact this entire document, come from a set of actual registry entries and are produced using the various registry tools.  This was done in order to show that a considerable amount of re-use and coordination is available to stewards at this time and well supported by the existing tools.  At the same time, proposed additional features and the mechanical use of them in a real examples are explored to improve the process.


text:
The terms, abbreviations and acronyms cited below shall be a part of the terms of the other companion volumes of this standard unless specifically cited otherwise.


text:
8. Remaining Clauses to be placed here as needed (8 to TBD)


text:
Messages and data frames specified in Clause 5 shall be composed of message elements. In some cases, these message elements shall be DFs, such as a message ‘Header’ DF, where each frame is in turn made up of primitive components. In other cases, these message elements shall be DEs. Any message specified in Clause 5 shall have all of its DEs and DFs specified in this clause, except those DEs that are primitive ASN.1 data types or those that are adopted from other functional areas. In the latter case, the referenced items can be found in the next clauses. For proper use of such elements, the governing standards shall be consulted.


text:
6.1 Data elements, data frames, and data frame references


text:
In the two tables which follow below definitive advice is given regarding the methods to be used when translating the ASN which is a part of this standard into the tagged formatting found in XML deployments.  This falls into two general areas, the actual tags to be used and the content rules to be used to express the ASN encoding.  For each data element, data frame or message a suitable preferred XML tag and a preferred formatting is given in the tables.  These follow the recommendation of the SAE <SITE NAME HERE> recommended practice for translating ASN into XML for ITS use.  
The proper use and nesting of these tags in messages shall follow the ASN developed in this and the base standard document and the rules for XML use cited in the reference documents.  In case of a conflict the ASN found in this document shall take precedence. The ordering of elements found in data structures expressed in XML shall follow that order specified in the ASN source listing provided in prior clauses.  Notably the “optional” keyword in ASN shall imply that the XML tags and content may also be optional in transmitted messages.  In order to ensure interoperation with others, the rendering of phrases and codes into XML found in 1512 (both the ITIS code and others) must also be agreed upon by implementers.  The provisions and options of SAE J2540 are wider than those that are easily supportable in XML. In order to successfully interoperate with other deployments using XML in this way a number of other issues must also be considered and agreed upon.  These are beyond the scope of this document.


text:
Note that there has been a multi-SDO discussion on the use of XML and ASN translations for ITS.  That work is covered in a document created primarily by MITRETEK and which is expected to become a published recommended practice of the SAE.  It deals primarily with detailed translations for those wishing to use ASN structured messages in XML and provides precise translation advice.  We have followed that advice here and presume that at the time of the published standard we will simply refer to the SAE standard as the set of translation rules used.  Note that there is also an ISO standard effort underway to do much the same thing with which we expect to remain in tight coordination.


text:
The table which follows provides the XML tags used by data frames and by messages.  Each of these complex structures is in turn made up of other data frames or data elements (each of which also have tags).  The lowest level of this hierarchy are the atomic data elements.  The data element tags and the format used for their content follows in the next table.


text:
The data element XML tags and the format used for their content is provided in the table below.   Note that when used in a data structure or a message that this ASN and tags shall be used (as opposed to the ASN name of the instance of the tag).  The presumption in this formatting is that the order and therefore the context of the tag is fully known by the data structure in which it is used and hence it serves no useful purpose to use the "instance name" of the ASN type appearing in the data frame.  [This also provides a level of ease, re-use, and convenience for those implementers who chose to build receiving message parsers that process each tag in unique ways]


text:
XML Tags and Content Formatting Rules for Data Elements


text:
Any tags required by MSG or DF definitions when an in-line ASN primitive element (INTEGER, IA5Sting, etc.) is defined shall have an XML tag in accordance with the cited rule set recommendations.
The tags determined for the entire family of the 1512 standard do not conflict with each other and can therefore be used together as needed.  This may not always be the case when XML tags of other standard (both inside ITS and elsewhere) are merged together.  In such an event the method of XML namespaces shall be used to preserve the tags of this standard.  The name space of "IM:" shall be used as the precursor to identity tags coming from this family of standards.  It is recommended that any tags from the common ITS data dictionary work should use the precursor "ITS:" to identify themselves.  It is recommended that any tags from the ITE-TMDD data dictionary work should use the precursor "TMDD:" to identify themselves.  It is recommended that any tags from the common SAE-ATIS data dictionary work should use the precursor "ATIS:" to identify themselves.  It is recommended that any tags from the common ITE-TCIP data dictionary work should use the precursor "TCIP:" to identify themselves.  
At this time an XML DTD or Schema is not available to represent the ASN encodings of this standard.


text:
This is an draft document for use by the CCC, subject to change.


text:
Data frames specified in Clause 5 are also composed of message elements defined by other standards bodies. These "foreign" elements are defined in the sections which follow.  These definitions were taken from the then current adopted standards of these organizations.  The referenced standards shall be consulted for further information regarding their proper use.  Unless otherwise noted in each entry, the below ASN.1 and XML definitions shall be taken as the governing definition when used in this standard, even when a more current revision of the standard is adopted by the issuing organization.


# Acronyms

Def:
Institute of Electrical and Electronics Engineers


Def:
External, used in example descriptive names


# Terms

Definition:
The term Data Structure which appears in the original volume is now more commonly called a Data Frame. The definition, which follows, remains the same.  Any construct (including DEs) used to represent the contents of a Data Dictionary.  From  a computer science perspective, data structures are viewed as logical groupings of DEs, used in this document to describe "messages" or parts of messages.  The data structure are comprised of the data elements of the Data Dictionary.  They don't "represent the contents of a data dictionary" directly -they organize them within a framework where useful systems can be constructed.  (One could say they present the contents of a Data Dictionary in a useful way).

UsedIn:
Hazmat P1512.3 Public Safety P1512.2 Traffic Incident P1512.1


Definition:
International Traveler Information Systems, the term commonly associated with the standard for incident phrases developed by the SAE ATIS Committee in conjunction with ITE TMDD and other standards.  This work contains a wide variety of standard phrases to describe incidents and is expected to be used throughout the ITS industry.  The codes found there can be used for sorting and classifying types of incident events, as well as creating uniform human readable phrases.  In the capacity of classifying incident types, ITIS phrases are recommended for used in many areas.  ITIS phrases can also be freely mixed with text and used to describe many incidents.


Definition:
A common method of exchanging messages made up of tags and values organized in a data structure and typically transported over common Internet formats such as HTTP.  Part of the purpose of this document is to show the methods of connection and steps to go from the ASN.1 source code to XML similar source code.


Definition:
The act of adding a module or namespace delimiter to an element, as in appending "ATIS." to DateAndTime to become ATIS.DateAndTime when used.  Pre-pending is needed to establish formal linkages between modules/namespaces in the source listings of ASN.1 and XML.


Definition:
An ASN.1 term to describe a formally declared new type of data element which can then be used (or re-used) by other data structures.  In ASN.1 the type definition basic form of declaring new structures and it must be made up of (i.e. resolvable to) other type definitions of from primitive types (int, string etc.).


Definition:
A programming term used in this document to mean...


