Updated: Oct. 10/2006
The
information below relates to the methodology used and the naming conventions
found in ITS standards when packaged as a schema family.
Each zip file and its content reflects a release of an ITS standard at some point in time. The numbering system used allows a precise control of the release and therefore accommodates the need to know exactly what baseline of a standard is being used by a deployment. The zip sets obtained from other standards may reflect either adopted or draft editions of their work, as well as work customized for specific deployment needs. The first few lines of each file normally also provide a comment header which describes the specific version which it came from and what database was used to create it.
Each zip file contains a number of other text files reflecting the content of the adopted standard as published by the IEEE. Specifically, these files are the XML schema expressions which reflect the content of the standard. These files all end with the *.XSD file type. The file manifest.txt (if present) contains a terse description of the files in the package as well.
The content of the standard is divided into several files following the Functional Area Data Dictionary (FADD) system used in ITS. The sections of the standard in the “External Data Concepts” clause are expressed here as other FADD files. FADDs are short abbreviations (typically 4~5 characters) for a group of related work. This term is used in naming the resulting files. A list of well know FADDs is provided at the end of this document. Each major development effort (typically corresponding to one standard) has a FADD name it uses. For example, the FADD for the IEEE Incident Management Message Set effort is “IM” and “TMDD” is used for the ITE Traffic Management Data Dictionary and its message set.
In order to use these schema files, the end deployment must first provide any additional missing content (typically local data) and remove any content not needed. This is discussed further below. It should be stressed that most schema sets released as part of an adopted standard ARE NOT SUITABLE FOR USE AS SHIPPED. It is expected that a user will need to customize this information before its practical use.
The details of this process are covered in other materials such as the User Guides, but this involves several general steps to produce a schema file set for local use:
1) Remove any messages from the standard you will not be using. Most deployments do not use the full and compete standard. Remove elements within the remaining defined types that will not be used. Remove any lower orphan elements as needed. The usual practice to determine what will be kept and removed is a multi-agency agreement regarding what data is to be shared and further details of how that sharing will occur.
2) Merge into the supporting schema files any additional content from other standards you will be using at the same time. Most deployments are not “pure,” in that they need some additional message content from other efforts to be used.
3) Note that the numbering of the other schema files is at this time given as “00-00-00” (discussed further below). If you wish to use a specific version of another schema, or a complete schema, replace that file with the proper one and revise the import and namespace headers in the other files to link to it. The complete ITIS FADD (the standard for all the traffic phrases) is typically treated in this way.
4) Add any required local stubs at this point in the proper files. Note that even if you do not provide any unique local content for local extensions, you must still provide a stub so that the complete schema will resolve. If additional content for messages, data frames, or enumerations are needed, they would be added here at this time.
5) Confirm that the resulting set of files correctly will compile with the XML syntax checker of your choice.
6) Name the folder which contains the work product something different than its original name so that you can easily determine what revision of your own work it is. It is suggested that you adopt a short FADD name and number the folder. So for example, your first effort might by placed in a folder called “MyDot-00-00-01” and the second one numbered –02 etc. By following this formula, your work will be readily exchangeable with other ITS deployments in the schema repository.
It should be obvious from the above that any ADOPTED schema set is simply a starting place for the deployment and that the deployment must make many design decisions regarding what parts of the standard to use as well as what other standards are to be used with it. Consult the FHWA created guides for the systems engineering process and for recommended ITS procurement practices for more information on this. In this context, adopted means that the SDO approval process (balloting, publishing, etc) was completed and that the committee felt the work was complete. It does not imply it is suitable, as provided, for any specific use.
Most schema files have a “lead” schema of some sort. This is typically the largest file and represents the content of the primary standard of the FADD that published it. It can also be recognized that the version naming on this file is typically not “00-00-00” (as is found in the supporting schemas files. Often this revision string is the same as the folder then encloses it. So for example, the file ATIS-Draft-03-00-74.xsd is found in a schema folder path of /atis/ATIS-03-00-74/ in this system.
All of the other files in the zip package are linked to this lead file in some way. Hence, they are needed to completely validate the files. With editing to remove unneeded content, some of the files may no longer be required. All of the content of these files is also found in the printed standard. Each FADD file is often a sub-set of another standard which the local deployment may decide to use in full.
Note that no *.WSDL file is provided because in most releases at this time no such dialog definitions were yet available. This is expected in future releases, and like the other files will require local editing to use. It should be noted that the WSDL files will also require customized to be used. In WSDL files (unlike XML schema files), the actual web service endpoint for the server and services (message dialogs) you will be using needs to be entered into the listing.
Using the IEEE “IM” schema (the standard is popularly called the 1512 standard) as an example, consider the name: IM-Draft-03-00-036.xsd This follows a five-part naming system that supports determining what release of the data is being used. All ITS schema releases from SDOs follow this naming, the details are as follows:
The FADD Term A well known short phrase from the list provided below. Beside the FADD terms listed, local deployments select their own names (I95, CaDOT, AzDOT, NbDOR, MyDot, AzTech, etc.) to describe their derivative work products from the standards There is not a formal registry of these names at this time.
The Type of File Release A term (if preset) which describes the type of release. Draft is the most common. Use of this term is still not universal. Some have suggested terms such as InBallot or Adopted, or Partial, etc. but the list remains unclear at this time. The word Local is used to indicate a local expansion file for that FADD (typically there will be one such file for every FADD file). What is of greater importance in use of the schema is that the name strings must match to import and use the file.
The Major Release The major release value of the standard. Typically only increased on balloted changes, but this varies with each SDO.
The Minor Release The minor release value of the standard. Typically only increased on balloted changes, but this varies with each SDO. Some SDOs do not use this value, while others do (i.e. TMDD Rev 2.1 is expressed as 02-01-xx here).
The Release Value The incremental release value of the standard. Typically this comes from the underlying database that is used and always increases. Not all values result in released schemas. Often this is changed every time the database is edited.
One can see from this example that the file contains Incident Manager Content (IM) and is the 3rd major edition of the standard, the 36th actual revision. Not that no minor revision value (00) is used in this example.
Using the same logic, the file: IM-Local-Draft-03-00-036.xsd contains the local content for this same release. Local files provided by the SDOs are typically simple blank endpoints and have no valid content in them when issued. Local files provided by a deployment may be the same, or may have considerable locally defined content in them. Such content can point to and use other content from the rest of the ITS work in the same fashion as other schemas do. With a large body of mature ITS work to select from, this is preferred over new invention.
Using the same logic, the file: ATIS-00-00-00.xsd contains the content from the ATIS (Advanced Traveler Information System) area and the edition or release from which it was taken is unknown (00-00-00). See the note on release editions below.
It is recommended that the schema set, both in its original form and in its final edited form, and in both zipped and un-zipped forms, be placed into a folder hierarchy as follows.
The files themselves all need to be in the same folder. They point to each other using local (rather than absolute) import path names, a convention of ITS XML styles.
The enclosing folder is normally named for the primary FADD and its release and enclosed in a folder names for the FADD, (in our example case /IM-03-00-36) . This is in turn enclosed in a folder with the FADD name and no revision (/IM). In this system, all the editions of the IM work are readily available at the same level. These should be put in a well named root, such as /ITSschemas which will be stable in location.
At the level of the IM folder, other FADD terms (ATIS, TMDD, or local deployments) are found. The folder named “ITS” is reserved for coordinated efforts between the SDOs using complete schemas that interoperate. Note that this tree allows adding new schema sets without disturbing the old. Lower case is preferred to avoid case issues with some computers.
The rest of the root of this can be any path desired. The resulting file path is then:
.../SomeXMLsite/ITSschemas/im/im-03-00-36/im-03-00-36.zip
Using the common schema repository as an actual example of this we have:
www.ITSware.net/ITSschemas/im/im-03-00-36/im-03-00-36.zip
While the files from the other standards efforts are numbered with “00-00-00” in the XML schema files, the actual edition to be used is normally made very clear in the actual adopted standard.
For example, in the IEEE and SAE style of standards, this can be found in Clause Two where each standard and its specific revision is given. Depending on the intention of the committee, that reference may state a specific standard revision or may state a standard and its adopted successors. Other standards have similar defining text.
Some zips files also contain other useful information for deployments, such as on-line web based documentation about the schema files. Such information, when present, can generally be found in the /docs folder of the zip or in a /docs folder in the repository.
As each new release of this information is published, they will be found alongside older folders and files in a form similar to the folder placement recommendations mentioned above. Older editions are never destroyed because it represents a baseline that some builders have already used. When new editions of a standard are issued, then a new schema family reflecting the changes made from that edition will be made available. Simply look for the new (larger) numbered folder to find the new release.
The following is a short list of common FADD terms found in the ITS standards
ADUS Archival Data User Services
ATIS Advanced Traveler Information System
C2C Center Two Center Commendations (SOAP and WSDL)
DSRC Dedicated Short Range Communications
HPMS Highway Performance Monitoring System
IM Incident Management
ITIS International Traveler Information System
ITS Intelligent Transportation Systems
JXDD Justice XML Data Dictionary
LRMS Location Referencing Message Set
NTCIP National Transportation Communications for ITS Protocols
RSPA Research and Special Programs (a DOT program used in 1512)
TCIP Transit Communications and Interfaces Profiles
TMDD Transportation Management Data Dictionary
The following files are part of the release IM-03-00-36.zip and represent a typical manifest list.
ATIS-00-00-00.xsd Portions of the ATIS schema used by the IM schema
ATIS-Local-00-00-00.xsd Local extensions to the ATIS schema
DSRC-00-00-00.xsd Portions of the DSRC schema used by the IM schema
DSRC -Local-00-00-00.xsd Local extensions to the DSRC schema
IM-Draft-03-00-36.xsd The IM schema (the primary schema of this standard)
IM-Local-Draft-03-00-36.xsd Local extensions to the IM schema
ITIS-00-00-00.xsd Portions of the ITIS schema used by the IM schema
ITIS-Local-00-00-00.xsd Local extensions to the ITIS schema
JXDD-00-00-00.xsd Portions of the JXDD schema used by the IM schema
JXDD-Local-00-00-00.xsd Local extensions to the JXDD schema
LRMS-00-00-00.xsd Portions of the LRMS schema used by the IM schema
LRMS-Local-00-00-00.xsd Local extensions to the LRMS schema
NTCIP-00-00-00.xsd Portions of the NTCIP schema used by the IM schema
NTCIP-Local-00-00-00.xsd Local extensions to the NTCIP schema
RSPA-00-00-00.xsd Portions of the RSPA schema used by the IM schema
RSPA-Local-00-00-00.xsd Local extensions to the RSPA schema
TCIP-00-00-00.xsd Portions of the TCIP schema used by the IM schema
TCIP-Local-00-00-00.xsd Local extensions to the TCIP schema
TMDD-00-00-00.xsd Portions of the TMDD schema used by the IM schema
TMDD-Local-00-00-00.xsd Local extensions to the TMDD schema
ReadMe.doc A description of how to understand and use these files
Manifest.txt This file
This documentation may be freely copied and used in
your own local documentation process as required.