TCIP Version 2.8.1 Read Me File
This file contains a variety of explanatory material that may be useful to reviewer of TCIP Version 2.8.1.
Files released in 2.8.1:
TCIP is released in 4 volumes. Volume 1 contains the narrative including Definitions, References, the Concept of Operations, Model Architecture, Conformance Criteria etc. It is contained in a file named “TCIP_2_8_1_Vol_I.DOC”.
Volume 2 contains the data element, data frame, message and dialog definitions. Volume 2 is released as 3 documents containing the data element definitions (Annex A), the data frame definitions (Annex B), and a document containing both the message and dialog definitions (Annexes C & D). These documents contain hyperlinks among the various defined items, and thus all three documents must be kept in the same folder, and the documents must not be renamed. The document names are “TCIP_2_8_1_Annex_A.DOC”, “TCIP_2_8_1_Annex_B.DOC”, and “TCIP_2_8_1_Annex_CD.DOC” respectively.
Volume 3 contains the TCIP XML Schema. It is published as “TCIP_2_8_1_Vol_III.DOC”. The schema is also provided in a pair of zip archives along with schemas produced for other related ITS standards in a set of ZIP files containing the baseline schema set (ZIP Archive “2 8 1 baseline XML archive revised.ZIP”), and a second schema set containing the duplicate workaround (ZIP Archive “2 8 1 dup XML archive revised.ZIP”)(see below).
Volume 4 contains the remaining annexes to the standard. It is published as “TCIP_2_8_1_Vol_IV.DOC”.
All of these files (except for the zip archives containing the sets described above) are provided in a zip archive named “TCIP_2_8_1_All_Files.ZIP”
List of Significant Changes from Version 2.7.1
- The definition of service at a stop now allows the service to be qualified by day type.
- Events, timepoints, and stoppoints in a schedule pattern may now optionally be specified by distance from the beginning of the pattern in a addition to the absolute location.
- Operator assignments may now optionally include the specification of the base for that assignment.
- The relationship between stoppoints and associated timepoints is clarified in the Concept of Operation. This includes additional text related to end of trip/start of trip scenarios.
- Clarified that trip numbers are unique within a TCIP Schedule release, not just within a run or block.
- Corrected PiPublishTextTimetable message to include the data frame PIPublishedSchedule. Version 2.7 erroneously substituted PIPublishedScheduleTable for PIPublishedSchedule.
- The scope of dialog “Subscribe Stoppoint Parking” was expanded to allow parking in a geographical vicinity to be requested, whether or not the requester specifies a transit stoppoint.
- IMIncident data frame was expanded to allow the source of an incident report to be specified, and toi add a count of involved vehicles.
- Added a naming convention for subset schemas of TCIP in recognition of the deployment support planning going on in the TCIP Tools TWG.
- The logging of data on the PTV at stoppoints was expanded to include door opening & closing times.
- Dialogs were added to allow Differential GPS data to be distributed using TCIP on a Push or on a Subscription basis.
- TCIP Versions 1.0 -2.7.1 contained a large number of different time and date related data elements. These have been consolidated into a much smaller number, and many have been eliminated. Data frames, and messages, have been updated to use the equivalent data elements from the new smaller set.
- Erroneous legacy references in the Conops to deleted dialog "Subscribe Onboard PRG Inputs" have been corrected.
- Dialogs were added to allow very basic GIS map layer data to be transferred to PTVs (e.g. load up data at the garage).
- The Fare Collection business area has been declared Informative NOT Normative. This business area will not be balloted with version 2.8.1. This was done due to concurrent efforts underway in the APTA UTFS standards effort & to avoid any potential conflicts between the two standards.
- A very basic capability to locate and provide directions to indoor locations was added.
- The occurrences of the ASN.1 WITH COMPONENTS structure were scrubbed to eliminate unneeded/incorrect occurrences. The ASN.1 for those data frames and messages was modified to include ASN.1 comments that serve as keywords for the XML translator. Eventually the Mini-Edit XML translation will automatically create equivalent XML CHOICE structures that have the same functionality as the ASN.1 SEQUENCE/WITH COMPONENT combination. At the time of the publication of TCIP Version 2.8.1, this Mini-Edit capability was not available. For version 2.8.1, the equivalent XML CHOICE structures were created manually.
- Added the capability to include a list of static signs in a stoppoint definition.
- Deleted a number of unused data elements and data frames from the standard. In general these items were orphaned as the standard evolved based on previously approved & incorporated comments. A few items were found to be unused because they were erroneously omitted from a ‘parent’ data frame or message. In these cases the ‘parent’ was corrected to incorporate the missing item.
- Added the ability to include multiple fares to a transit itinerary (e.g. student fare, senior fare). This ability is not extended down into the SAE ATIS itinerary definition. Consequently it is currently (in version 2.8.1) possible to specify multiple fares for the itinerary as a whole, but only a single fare for individual segments (legs) of the journey. We will be submitting a comment to SAE to have this corrected in the next release of the SAE ATIS Standard.
XML Schema Changes and Issues
A number of XML schema generation issues were named and documented as part of the TCIP 2.7.1 release process in the associated read me file. The 2.7.1 schema read me file is included at the end of this document for reference. The differences in approaches for the schema for version 2.8.1 are documented here.
- The Union Problem. The union problem did not have an identified solution as of the publication of version 2.7.1. For version 2.8.1 a resolution has been identified, but is not yet supported by the Mini-Edit XML generation facility. Consequently the solution has been implemented manually in the TCIP Version 2.8.1 Schema. The solution is to include the definition of the number space allowed for local extensions in the standard schema rather than in the TCIP local schema.
For example consider the declaration:
CPT-TrafficSignalType ::= ENUMERATED {
normal (1),
flashingRed (2),
flashingYellow (3),
busOnly (4),
qeueJump (5),
rightOnRed (6),
leftOnRed (7),
--8-127 reserved
--128-255 local use
... -- # LOCAL_CONTENT
}
In TCIP Version 2.7.1, this was translated into XML as:
<xs:simpleType name="CPT-TrafficSignalType">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:unsignedInt">
<xs:minInclusive value="1"/>
<xs:maxInclusive value="7"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="normal"/>
<xs:enumeration value="flashingRed"/>
<xs:enumeration value="flashingYellow"/>
<xs:enumeration value="busOnly"/>
<xs:enumeration value="qeueJump"/>
<xs:enumeration value="rightOnRed"/>
<xs:enumeration value="leftOnRed"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="local:CPT-TrafficSignalType"/>
</xs:simpleType>
</xs:union>
</xs:simpleType>
This is a union of the standard-defined numeric values (1-7), with the standard defined string values, and the locally enumerated simple type. The problem arose because the locally defined simple type was a union of the locally defined numeric values with the locally defined string values. Consequently the standard structure contains a union of a union which is a violation of the XML standard. This problem exists throughout many of the existing ITS standards. The solution for version 2.8 is to include the numeric values allowed to be used in a local extension in the definition of the TCIP standard. The local extension schema then specifies only the locally defined string values. This eliminates the need for the locally defined data element to be a union, and thus eliminates the violation of XML syntax.
The standard definition of this data element in TCIP for 2.8 is modified to look like this:
<!-- Descriptive Name: CPT-TrafficSignalType -->
<xs:simpleType name="CPT-TrafficSignalType" >
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:unsignedInt">
<xs:minInclusive value="1"/>
<xs:maxInclusive value="7"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="normal"/>
<xs:enumeration value="flashingRed"/>
<xs:enumeration value="flashingYellow"/>
<xs:enumeration value="busOnly"/>
<xs:enumeration value="qeueJump"/>
<xs:enumeration value="rightOnRed"/>
<xs:enumeration value="leftOnRed"/>
</xs:restriction>
</xs:simpleType >
<xs:simpleType>
<xs:restriction base="xs:unsignedInt">
<xs:minInclusive value="128"/>
<xs:maxInclusive value="255"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="local:CPT-TrafficSignalType" />
</xs:simpleType>
</xs:union>
</xs:simpleType>
- WITH COMPONENTS. TCIP Version 2.7.1 and earlier versions contain instances of the ASN.1 WITH COMPONENTS construct that are not accurately translated into XML. The construct is used in TCIP to indicate that at least one of a set of optional fields must be present in a data frame or message. The translation in these versions allowed any number of the items to be present in an XML instance, including zero. The problem arises because there is no SEQUENCE construct in XML that enforces this type of requirement. The identified fix is to use a SEQUENCE construct in ASN.1 and a CHOICE construct in XML, that enforce the same requirements for fields being present.
For example the declaration:
PIAmenitiesDesired ::= SEQUENCE {
which SEQUENCE{
stop-attributes SEQUENCE (SIZE(1..20)) OF CPT-StoppointAttribute OPTIONAL,
ptv-attributes SEQUENCE (SIZE(1..20)) OF CPT-PTVehicleAttribute OPTIONAL
}
-- # CHOICE_SET MIN=1 UNTAGGED
}
(WITH COMPONENTS {..., stop-attributes PRESENT}|
WITH COMPONENTS {..., ptv-attributes PRESENT })
indicates that either stop-attributes, or ptv-attributes must be present, but both may also be present. The COICE_SET keyword will eventually allow for automatic translation of the ASN.1 to XML. The UNTAGGED keyword indicates that the tag for element ‘which’ is not required to be conveyed with a message instance. The XML declaration for this data frame in version 2.8.1 looks like this:
<!-- Descriptive Name: PIAmenitiesDesired -->
<xs:complexType name="PIAmenitiesDesired" >
<xs:sequence>
<xs:element name="which" >
<xs:complexType>
<xs:choice minOccurs="1" maxOccurs="2" >
<xs:element name="stop-attributes" minOccurs="0">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="20">
<xs:element name="stop-attribute" type="CPT-StoppointAttribute" />
</xs:choice>
</xs:complexType>
</xs:element>
<xs:element name="ptv-attributes" minOccurs="0">
<xs:complexType>
<xs:sequence minOccurs="1" maxOccurs="20">
<xs:element name="ptv-attribute" type="CPT-PTVehicleAttribute" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- UNTAGGED # CHOICE_SET MIN=1 UNTAGGED -->
</xs:sequence>
</xs:complexType>
- Multipath and Circular Reference Problems. The status of the multipath and circular reference problems are unchanged from TCIP Version 2.7.1, as there has been no change in status in the ITS community as a whole. Consequently the same work-arounds used in the release of TCIP Version 2.7.1 are present in TCIP Version 2.8.1. These are described in the TCIP 2.7.1 release notes which are replicated below.
TCIP 2.7.1 Release Notes Replicated for Reference
TCIP 2.7.1 Schema Files
The primary mechanism for encoding and transferring TCIP messages, and message files is in the Extensible Markup Language (XML). The TCIP XML Schema provides a machine readable definition of the TCIP messages, data frames and data elements in a format readable by commercial XML parsers. The schema can be used by commercial software to create and interpret valid TCIP message instances, and to detect invalid message instances.
TCIP also provides for a variety of local extensions to TCIP messages. These extensions are defined in the TCIP local extension schema. This local schema is intended to be edited locally to add local content to the extensible portions of TCIP.
TCIP imports data definitions from other ITS standards. These other standards also have published XML schemas, and in some cases their own local extension schemas. These other standards are in a variety of stages of completion as of the date of publication of TCIP 2.7.1.
This distribution contains sets of schema files (file extension .xsd) that include not only TCIP, but its associated local extension schema and schema files for the other standards. Schema files for external standards may not contain the entire baseline schema for that standard, but may be ‘partial’ schemas that exclude data declarations that are not used by TCIP.
For example the full IM schema references the US Department of Justice JXDD Schema, however, since none of these references are used in the IM data definitions used by TCIP, a subset of IM is used that does not reference JXDD. This eliminates any need to distribute the JXDD Schema with TCIP.
The ITS community is in the process of adopting a naming standard for ITS Standard Schema files. The file naming convention is std_X_Y_Z_type.xsd. In this notation std indicates the name of the standard (e.g. tcip, lrms, im), X, Y, and Z represent the 3 part version identifier for the standard (for TCIP 2.7.1, X=2, Y=7, and Z=1). The type field contains one of ‘Local’ indicating that the file is a local extension schema, ‘Partial’ indicating that the schema is a subset of the data declarations in the complete standard, ‘DRAFT’ indicates that the standard is complete but not an approved, balloted standard.
Normally to use the schema set, it is not necessary to open each of the schema files individually. Opening the TCIP schema, with the other files stored in the same folder, will cause most parsers to open the other schemas files as needed.
Figure 1 depicts the relationships among the ITS Schema Standards relevant to TCIP 2.7.1.
Schema Validation & Related Schema Modifications
The TCIP 2.7.1 Schema and the related schema sets have been validated using XML Spy by Altova version 2004 release 3. Earlier versions of TCIP and other ITS Standards schemas have also been validated using XML Spy. Beginning with version 2.7.1, APTA began work on validating the schema in other commercial environments including Visual Studio 2003 (Microsoft .NET Framework).
The .NET framework has some limitations on schema sets, that are not present in XML SPY. The .NET framework also performs some validation checks that are not performed by XML SPY. In validating in the .NET framework, the first issue that arises is that .NET does not allow circular schema references. That is to say if Schema A references Schema B, .NET cannot tolerate Schema B, also referencing Schema A. For convenience, this limitation may be referred to as “The Circular Reference Problem”. As illustrated in Figure 1, we have instances of the circular reference problem between ATIS and TCIP, as well as between ATIS and IM.
To work around the circular reference problem, the ITS Standards Schema files distributed with TCIP 2.7.1 were modified to eliminate these circular references. This was accomplished by: 1) locating the data definitions in TCIP and IM that are imported by ATIS, 2) copying those data definitions into the bottom of the ATIS schema, and 3) removing the namespace references to IM and TCIP in the ATIS schema. The relationships that were thus severed are represented by solid blue lines in Figure 2.
As part of this same process, other relationships between schemas were examined. This examination revealed that the references from TMDD to ITIS, and from IM to ITIS were
present to support the definition of data items that were not required by TCIP 2.7.1. Accordingly, these data items were removed from the IM and TMDD Schemas, along with the namespace references to ITIS in TMDD and IM. These are reflected by the blue dotted lines in Figure 2.
Revalidation using Visual Studio revealed that the .NET environment still failed to validate the schema set. The multiple paths from TCIP to TMDD, and ITIS (direct and through ATIS), still caused validation errors, as illustrated by the red lines in Figure 2. Interestingly the multiple paths to LRMS were not detected and flagged by Visual Studio. For convenience this problem is termed “The Multipath Problem”.
The schema file set reflected by Figure 2 is contained in folder “Baseline Schemas” distributed with TCIP 2.7.1. The multipath problem and the union problem (see below) are not resolved in this schema set.
To address the multipath problem, a rather inelegant work-around has been developed. Each schema that is reachable by more than one path was copied and renamed. The renaming occurs both at the filename level and at the namespace level. This LRMS is referenced both by TCIP and by ATIS, LRMS becomes TCIP-LRMS, and ATIS-LRMS. This causes the .NET environment to interpret each copy of LRMS as a completely distinct schema, even though both copies have the same content (other than the namespace identifier). This workaround is illustrated in Figure 3. The file set reflected by Figure 3 is contained in the folder Dup Schemas distributed with TCIP 2.7.1. The ‘Dup Schemas’ file set resolves the circular reference problem and the multipath problem, but does not address the union problem (see below).
The Union Problem
The ITS Standards Community uses a convention whereby an enumerated type may be represented by a defined string or a corresponding code number. As an illustration consider the data element definition below:
Colors ::= ENUMERATED {
black (1),
gray (2),
white (3),
red (4),
blue(5)
-- values 6-127 reserved
-- values 128-288 local use
… --#LOCAL_CONTENT
}
This definition is interpreted to mean that the standard defines 5 standard colors. Each color can be represented in a message by its name (e.g. ‘blue’) or its corresponding code number (e.g. ‘5’). The standard reserves the right to add new colors with code values in the range 6-127 in the future. Local implementations may add their own colors, but must assign codes to the local colors in the range 128-255.