SIRI XML schema

SIRI XML Document Structure

Notation for XML model structures of SIRI messages

General

In the SIRI documentation, SIRI XML structures are shown in a tabular form. A separate table is used for each major SIRI request and response message; additional tables are used for the major child elements making up a complex message. To save space, table headings are not repeated on individual tables, but are shown only in the example. The tables use a consistent set of conventions to describe the XML elements and their constraints.

Example of XML Structure Notation

Organizational Group	Name of Element	Min : Max	Data Type	Description
MessageResponse			+Structure	Returns data for a Message Request
Attributes	srsName	0:1	xsd:string	Default GML coordinate format for any spatial points defined in response by Coordinates parameter
Log	ResponseTimestamp	1:1	xsd:dateTime	Time individual response element was created
Endpoint	ProducerRef	0:1	➡️ ParticipantCode	Participant reference that identifies producer of data. May be available from context
Endpoint	:::	0:1	AddGroup	MyAddress Group elements
Status	Status	0:1	xsd:boolean	Whether the complete request could be processed successfully or not. Default is true
Status	ErrorCondition	0:1	See below	Description of any error or warning conditions that apply to the overall request
Status			choice	One of the following Error codes
Status	a)CapabilityNotSupportedError	-1:1	+ Error	Error: Capability not supported
Status	b)OtherError	-1:1	+ Error	Error other than a well defined category
Status	Description	0:1	➡️ ErrorDescription	Description of Error
Payload	ExpectedLifeTime	1:1	PositiveDurationType	How long I expect to live. Time interval
Payload	MyWay	0:1	foo bar	Which way I did it. Default is ´foo´
Payload	XxxDelivery	0:*	+Structure	See SIRI Part 3 - Functional Service and SIRI Framework

---

A SIRI XML document is a computer file containing XML data that adheres to the SIRI schema. It must have a root Siri element that indicates the schema and version to which the document conforms. The document can then be validated against the schema to ensure correctness, meaning it is well-formed XML that conforms to the SIRI schema and satisfies key referential integrity constraints specified by the SIRI XML Schema

Here is an example

<Siri xmlns="http://www.siri.org.uk/siri" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="2.0" xsi:schemaLocation="http://www.siri.org.uk/siri ../../xsd/siri.xsd">

Structure of the xxxDelivery element

The xxxDelivery element consists of two sections:

1. Header

The header contains a mandatory ResponseTimestamp element

2. Payload

corresponds to the description of the object itself independently of any and other headers

Example

Here's an example of a ServiceDelivery element with a header and a payload

<Siri xmlns="http://www.siri.org.uk/siri" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="2.0" xsi:schemaLocation="http://www.siri.org.uk/siri ../../xsd/siri.xsd">
 <ServiceDelivery>
  <!--=======HEADER================================================== -->
  <ResponseTimestamp>2004-12-17T09:30:46-05:00</ResponseTimestamp>
  <ProducerRef>KUBRICK</ProducerRef>
  <Status>true</Status>
  <MoreData>false</MoreData>
  <!--=======PAYLOAD============================================== -->
  <GeneralMessageDelivery version="2.0">
   <ResponseTimestamp>2001-12-17T09:30:47.0Z</ResponseTimestamp>
   <RequestMessageRef>12345</RequestMessageRef>
   <Status>true</Status>
   <GeneralMessage formatRef="string">
    <RecordedAtTime>2001-12-17T09:30:47.0Z</RecordedAtTime>
    <InfoMessageIdentifier>00034567</InfoMessageIdentifier>
    <InfoMessageVersion>2</InfoMessageVersion>
    <InfoChannelRef>WARNINGS</InfoChannelRef>
    <ValidUntilTime>2001-12-17T09:30:47.0Z</ValidUntilTime>
    <Content>Beware the Ides of March</Content>
   </GeneralMessage>
   <GeneralMessageCancellation>
    <RecordedAtTime>2001-12-17T09:30:47.0Z</RecordedAtTime>
    <InfoMessageIdentifier>00034564</InfoMessageIdentifier>
    <InfoChannelRef>WARNINGS</InfoChannelRef>
   </GeneralMessageCancellation>
  </GeneralMessageDelivery>
 </ServiceDelivery>
</Siri>

SIRI Schema Overview

The SIRI XML schema is encoded as a W3C .xsd schema, and is modularized into a number of reusable sub schemas and type packages. The schema and has been validated against mainstream validators and there are working applications using common tools.

Referencing the SIRI Schema in the XML Documents

For an XML document to be SIRI-conformant, it must include a reference to the root schema file (usually siri.xsd).

XML Document Validation with SIRI

XML document validation is the process of verifying a given XML document against its schema to ensure its correctness. For a document to be considered correct:

Validation Requirement	Status
It must be well-formed XML, adhering to the basic rules of XML syntax.	✅
It must conform to the SIRI XML Schema, following the specific structure and data types defined in the schema.	✅
It must also satisfy any referential integrity constraints imposed by the SIRI schema.	✅

Validation is typically performed using automated tools.

Well Formed XML

Well-formed XML is XML that meets the basic syntax rules for XML as laid down in the EW3C specification.

Syntax Rule	Status
Base data types (dates, numbers, strings, booleans) must have correct formats.	✅
All data elements shall be enclosed within tags, starting with '<' and ending with '>'.	✅
Special characters must be escaped using numeric values or symbols, e.g., '&' for '&' when necessary.	✅

XML Document Conformance

An XML document is considered conformant if it successfully validates against its schema. This validation encompasses the following checks:

Element Validation

• Only permitted element tags are allowed (note that some tags may allow the embedding of other schemas).
• Mandatory elements must be present.
• Minimum and maximum cardinalities must be satisfied.
• All elements must appear in the required order.

Attribute Validation

• Only permitted attributes are allowed (in any order).
• Mandatory attributes must be present.

Data Type Validation

• Values for enumerations must be one of the allowed values.
• Data types must satisfy their specified format, e.g., date, time, boolean, integer, URI, etc.