TransXChange

Diagnostics & Validation

The TransXChange Publisher includes a diagnostic function to apply additional consistency checks to TransXChange documents over and above those that can be expressed in the TransXChange XML Schemas alone.

The full list of integrity rules is published in the TransXChange Schema Guide. This page provides a summary of the integrity rules that are implemented as diagnostic checks for the current publisher. When a document is published, any exceptions are shown in the validation report at the end of the published pdf document.

Syntactic Validation Rules - XML: Schema validation

XML's inbuilt mechanisms are used in the TransXChange schemas to enforce a number of basic integrity checks of data within a TransXChange document. A document must satisfy these constraints, or it is not 'well-formed' and will not be processed further by the TransXChange Publisher or other XML tools.

XML enforced checks include:

  • The Naming, Order, Cardinality and optionality of elements and attributes is enforced.
  • Data types are specified for dates, times, durations and other common data types. For example times must be of the form hh:mm:ss
  • Restricted values are enforced by enumerations - see individual tables of allowed values under the schema guide entry for different constrained elements.
  • Some additional rules for encoding formatted elements are enforced by regular expressions. These can be used to specify which characters or digits may occur in which position of a value within a custom data type. For example, Registration numbers must have a particular format.
  • Minimum and maximum lengths can be specified.
  • Uniqueness and keyref constraints are enforced. These can be used to ensure that referential integrity is maintained within the document - i.e. that any element referenced by a cross reference is declared elsewhere in the document.

To check whether your document passes XML validation you can use an XML validation tool.

Performing schema validation takes some time on a large document. In the enhanced publisher you can suppress revalidation of a document that is already known to be correct using the GUI advanced options.

Semantic Integrity Rules - TransXChange Diagnostics

In addition to the syntactic integrity rules, TransXChange specifies a number of semantic rules that need to be applied by applications parsing a TransXChange XML document. These are subdivided into two categories:

  • Intrinsic Constraints Consistency checks that can be applied without reference to external data. For many of these, a sensible recovery action can be taken.
  • Extrinsic Constraints Checks of data values that require reference to an external source. Whether these need to be applied depends on the availability of the relevant data sets, and the purpose of the application.
    • The 2.1_1 version of the publisher make no external checks.
    • The 2.2a_1 and later versions of the publisher check for external NaPTAN references when using the route mapping option. Stops without data are listed in the route map key.
Rules are assigned a Severity
Severity Meaning Action
1 Fundamental Inconsistency - Schedule cannot be accurately interpreted. Report as serious error. Reject for registration.
2 Inconsistency - Default Remedial action possible, but statutory Registration requires clarification. Report, apply remedy automatically. Reject for registration.
3 Inconsistency - Default Remedial action possible. Report, apply remedy automatically.
4 Data reference does not exist in external source. Report as missing.
5 Ancillary data reference does not exist. Report as missing.
6 Minor data inconsistency. Report, leave uncorrected.


Integrity rules - Implemented by the TransXChange Publisher

The TransXChange Publisher implements a subset of the integrity rules listed in the TransXChange Schema Guide, including all severity 1 and severity 2 errors. Any exceptions are listed in a diagnostics section at the end of the published pdf document, with a severity.

  • From the GUI, the checks shown are are carried out by the Publisher if the option to include the diagnostics is selected .
  • From the command line interface, diagnostics are produced unless the novalidation option is specified to suppress integrity rule checking.
Group # Rule Name Description Cat Sev Remedy
Metadata Dc1 Valid FileName File name is made up of recommended elements. Int 6 Allow, but give warning.
Registration

 

RG1 Justifications Short term registrations must have at least one justification element (Severity 2 – i.e. required for submission). Int 3 >Warning. (+TXC 2.4)
RG2 New stops Only Cancellation may omit new stops required Int 4 Warning. (+TXC 2.4)
Serviced Organization
Eo2 Serviced Organization no cyclic References. Parent or ancestor should not be self. Int 3 Ignore parent.
Period

 

Tp1 Unique Operation Profile weeks PeriodicDayType/ Weeks should be distinct. Int 3 Ignore overlap.
Tp2 Valid Date Ranges. EndDate should be after StartDate on ValidityPeriod and other ranges. Int 3 Use start date for both, and report.
Service
Sv2 Appropriate Service type. The following combinations of ServiceClassification are not allowed.
  • NormalStopping and any other type except RuralService
  • ExcursionOrTour and any other type.
Int 2 DEPRECATED (TXC 2+4)
Operator

 

Op2 Distinct Operator References RegisteredOperator of a Service should not be the same as AssociatedOperator Int 3 Ignore associated operator.
Op3 Distinct Associated Operator roles. Each AssociatedOperator should only be referenced once by a given service for a given role. Int 6 Ignore duplicate references.

Route

Rs1 Linear routes. In a sequence of RouteSection instances making up a given Route, the To/ StopPoint of the last link of a given RouteSection should be the same as the From / StopPoint of the first link of the succeeding RouteSection in the Route. Int 1, p Reject.
Rs2 Route section link direction. All route links in a route section should have the same Direction. Int 6, p Use first direction found.
Rl1 Route Link sequence stop references. In a collection of successive route links, 'To' stop point reference of previous link should be same as 'From' stop reference of next successive link. Int 3, p Ignore second usage.
 
RI2 Route Link distinct endpoints. ’From’ and ’To’ stop points of a RouteLink should be distinct, i.e. not the same. Int 6 Allow, but issue warning.
 
R14 Stop Type Usage Within a given route Fixed stops (i.e. stops of type MKD) should not fall within the area of Hail and Ride stops (i.e. stops of type HAR) Int 2 Report as disallowed (TXC+2.4

Journey Pattern

Jp1 Timing endpoints. Start and end stops of a journey pattern should have a StopType TimingStatus of principle point. Int 4, p Treat as PTP regardless.
Jp2 Distinct journey pattern Interchange References Inbound and outbound journey patterns at an interchange should normally be distinct. Int 6 Allow, but issue warning.
Jps1 Section Projection. If there are route sections, then for each JourneyPatternSection, there should be a corresponding RouteSection with the same number of links. Int 1 Not implemented Reject.
Jps2 Linear journey patterns. In a sequence of JourneyPatternSection instances making up a given JourneyPattern, the To / StopPoint of the last link of a given JourneyPatternSection should be the same as the From / StopPointof the first link of the succeeding JourneyPatternSection in the JourneyPattern. Int 1, p Reject.
Jptl1 Journey Pattern timing link sequence stop references. In a collection of successive timing links, 'To' stop reference of previous link should be same as 'From' stop reference of next successive link. Int 6, p Ignore second usage.
  Jptl3 Route Link Projection. If a JourneyPatternTimingLink references a RouteLink, the start and end stops of both links should correspond. If the Direction of the JourneyPatternTimingLink is the same as that of the RouteLink, the respective start points should be the same and the respective ends point should be the same. If the Direction is opposite, the JourneyPatternTimingLink start point should match the RouteLink end point, and vice versa. Int 1, p Reject
Vehicle Journey Vj1 Cyclic vehicle journey references. Referenced VehicleJourney for link usage should not be self, either directly or indirectly. Int 3, p Ignore reference.
Vj2 Vehicle journey link references. If a VehicleJourney references a VehicleJourney for its link usage, there should be no VehicleJourneyTimingLink instances present for the referencing journey. Int 3, p Ignore links in referencing journey.
Vj3 Mixed Frequency Group In a group of journeys with the same end making up the same frequent service period, not all vehicle journeys in the group have the same minimum, maximum and scheduled frequencies or minutes past the hour. Int 3, p Use values from first (+TXC2.2)
Vjtl1 Vehicle journey timing link projection. For each VehicleJourneyTimingLink there should be a corresponding JourneyPatternTimingLink. Int 1 Reject.
Vjtl3 Short working reference. Any ShortWorking / JourneyPatternTimingLinkRef instances should reference a timing link of the vehicle journey that contains it. Int 3, p Ignore short working.
  Vjpl2 Positioning link stop point. One end of a PositioningLink sequence should reference a stop in the journey pattern. Int 3, p Ignore positioning link sequence.
         


Page last updated: 2013.03.30