Skip to content

Structure & Compatibility

Jump to bottom
Eliot edited this page Oct 11, 2023 · 10 revisions

SIRI Schema Structure

The SIRI XML schema adopts a modularized approach, with each module aligning with a specific component or package defined in the SIRI specification. These schema files are structured within directories that reflect the components and packages within the SIRI design model.

Advantages of a Modular Schema

A modular schema design offers several advantages within the context of SIRI:

  • Selective Usage: Users can selectively incorporate only the required elements from the schema, providing flexibility and efficiency for specific application needs.

  • Isolation of Changes: When updates or changes are necessary, they can be confined to the relevant schema components, minimizing the impact on the entire system.

  • Recommended XML Editors: To effectively navigate and edit the schema, it is strongly recommended to use specialized XML editors such as XmlSpy or Oxygen. These editors enhance the development experience and ensure compliance with the SIRI schema.

Folders

For each SIRI-XML release the top level directory contains:

\schema\1.00\ReadMe.md  
\schema\1.00\Releases-notes [List of changes]   
\schema\1.00\Siri-spp    [Altova XmlSpy PROJECT]
\schema\1.00\Siri-xpr    [Oxygen PROJECT]
\schema\1.00\.travis.yml [Travis CI configuration file for automated testing of the SIRI schemas.]
\schema\1.00\xsd                [XSD schemas]

	\schema\1.00\xsd\siri.xsd [SIRI base schema]
	\schema\1.00\xsd\siriSg.xsd [SIRI supplementary schema]
	\schema\1.00\xsd\siri_all_functionalServices.xsd [Imports all of the SIRI functional service schemas]
	\schema\1.00\xsd\siri_connectionMonitoring_service.xsd [The SIRI connection monitoring service schema]
	\schema\1.00\xsd\siri_connectionTimetable_service.xsd [The SIRI connection timetable service schema]
        \schema\1.00\xsd\siri_discovery.xsd [The SIRI discovery service schema]
        \schema\1.00\xsd\siri_estimatedTimetable_service.xsd [The SIRI estimated timetable service schema]
        \schema\1.00\xsd\siri_facilityMonitoring_service.xsd [The SIRI facility monitoring service schema]
        \schema\1.00\xsd\siri_generalMessage_service.xsd [The SIRI general message service schema]
        \schema\1.00\xsd\siri_situationExchange_service.xsd [The SIRI situation exchange service schema]
        \schema\1.00\xsd\siri_stopMonitoring_service.xsd [The SIRI stop monitoring service schema]
        \schema\1.00\xsd\siri_stopTimetable_service.xsd [The SIRI stop timetable service schema] 
        \schema\1.00\xsd\siri_vehicleMonitoring_service.xsd [The SIRI vehicle monitoring service schema]
        \schema\1.00\xsd\siri_wsConsumer-Document.wsdl [A WSDL file for the SIRI web service consumer (Document)]
        \schema\1.00\xsd\siri_wsConsumer-WSDL2.wsdl [A WSDL file for the SIRI web service consumer (WSDL2)]
        \schema\1.00\xsd\siri_wsConsumer.wsdl [A WSDL file for the SIRI web service consumer]
        \schema\1.00\xsd\siri_wsProducer-Document.wsdl [ A WSDL file for the SIRI web service producer (Document)]
        \schema\1.00\xsd\siri_wsProducer-WSDL2.wsdl [A WSDL file for the SIRI web service producer (WSDL2)]
        \schema\1.00\xsd\siri_wsProducer.wsdl [A WSDL file for the SIRI web service producer]

	\schema\1.00\xsd\acsb\... [ACSB namespace]
	\schema\1.00\xsd\datex2\... [DATEX II namespace]
	\schema\1.00\xsd\gml\... [Geography Markup Language namespace]
	\schema\1.00\xsd\ifotp\... [International Federation of Public Transport Fare Information Model namespace]
	\schema\1.00\xsd\siri\... [SIRI namespace]
        \schema\1.00\xsd\siri_model\... [SIRI model namespace]
	\schema\1.00\xsd\siri_model_discovery\... [SIRI model discovery namespace]
	\schema\1.00\xsd\siri_utility\... [SIRI utility namespace]
	\schema\1.00\xsd\wsdl_model\... [WSDL model namespace]
	\schema\1.00\xsd\xml\... [W3C XML namespace]

\schema\1.00\examples\... [Example  xml documents]
        \schema\1.00\examples\siri_exa_framework\...
        \schema\1.00\examples\siri_exm_CM\...
        \schema\1.00\examples\siri_exm_CT\... 
        \schema\1.00\examples\siri_exm_ET\...  
        \schema\1.00\examples\siri_exm_FM\...  
        \schema\1.00\examples\siri_exm_GM\...  
        \schema\1.00\examples\siri_exm_PT\...  
        \schema\1.00\examples\siri_exm_SM\...  
        \schema\1.00\examples\siri_exm_ST\...  
        \schema\1.00\examples\siri_exm_SX\...  
        \schema\1.00\examples\siri_exu_capability\...
        \schema\1.00\examples\siri_exu_discovery\...   
       
\schema\1.00\.travis\... [xmllint-check script]
        \schema\1.00\.travis\travis-ci_git-commit.sh
        \schema\1.00\.travis\xmllint-check.sh

Referencing the SIRI Schema in the XML Documents

An SIRI XML document contains data marked up with XML tags that conform to a given version of the SIRI schema.

The schema to use to validate the document is given by the xsi:schemaLocation attribute in the document header. For example, siri.xsd in the following excerpt.

<?xml version="1.0" encoding="UTF-8"?>
<!-- (C) Copyright 2005-2012 CEN SIRI -->
<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============================================== -->
  <ConnectionMonitoringFeederDelivery version="2.0">
  :::: contents
  </ConnectionMonitoringFeederDelivery>
 </ServiceDelivery>
</Siri>

Ensuring Compatibility in SIRI Schema Evolution

When developing new versions of software, it's highly desirable to maintain backward compatibility, which means that the software should still work with older data artifacts, such as XML documents created under previous versions. SIRI schema evolution aims to support compatibility with previous versions.

Guidelines for Compatibility

In the context of XML schema, several considerations apply to ensuring compatibility.

  • The following changes can break strict XML document compatibility, causing previously valid documents to fail validation:

    • Changing the names of existing elements or attributes.
    • Changing the values of existing enumerations (e.g., correcting typos).
    • Changing the default value for an attribute.
    • Deleting an existing tag.
    • Deleting an existing attribute.
    • Changing the order of existing elements.
    • Reducing the cardinality of an existing element.
    • Making an optional element mandatory.
    • Making the definitions of a data type stricter (e.g., requiring a name to begin with "X").

  • The following change does not break strict compatibility, but changes the semantics of the interpretation:

    • Adding a default value for an attribute.

  • The following changes do not break backwards compatibility of XML documents (but may require an updated binding):

    • Adding new tags or elements.
    • Adding new enumeration values to an existing element.
    • Changing comments on elements.
    • Adding an XML group to organize elements in the existing sequence.
    • Increasing the cardinality of an existing element.
    • Making a mandatory element optional (unless this introduces ambiguity with succeeding elements).
    • Replacing a choice with an element whose substitution group covers all the choice elements.

Deprecated Changes

Certain changes that break strict compatibility, such as correcting the spelling of an enumeration or dropping an element or attribute, can be done in a backward-compatible way by retaining the old element or value with a "deprecated" status. The deprecated value may be dropped after a while at an appropriate major release.

Clone this wiki locally