TransXChange Publisher Validation & Diagnostic Rules

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 teh 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.

Serviced Organization

Eo2

Serviced Organization no cyclic References.

Parent or ancestor should not be self.

Int

3

Ignore parent.

Period

Tp2

Valid Date Ranges.

End date should be after start date 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

Reject

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.

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.

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 / StopPoint of 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.

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 positioning link sequence should reference a stop in the journey pattern.

Int

3, p

Ignore positioning link sequence.

GovTalk logo