Page Comparison

DataManagedObject, together with Version and Codespace, provides uniform, common properties for all NeTEx entities. DataManagedObject is the abstract “upper object” of the NeTEx implementation and all first class NeTEx entities are specialisations of it.

...

Data exported to an XML document from a repository represents a snapshot of the state of a particular version of the data at a particular moment in time. The NeTEx XSD is therefore primarily concerned with instances of Transmodel's ENTITY IN VERSION. That is to say, data elements in a NeTEx XML document represent a particular version of each ENTITY. Even if a basic implementation of a repository holds only a representation of the current state of an ENTITY, rather than its entire history of versions, every time it makes an export it is in effect creating an ENTITY IN VERSIONfor the time of export; if the current version in the repository is changed, two successive exports would result in different states, i.e. different instances of the appropriate ENTITY IN VERSION.

In NeTEx, ENTITY IN VERSION is implemented as EntityInVersion; this is further specialised as DataManagedObject which also reifies certain other separate Transmodel concepts into a single abstract XML class. It provides a convenient way to bring together common versioning, responsibility, and validity condition features from Transmodel, together with the XML extension mechanisms supported by NeTEx, in a way that is completely uniform for all NeTEx objects and so is simpler to implement.

NeTEx uses Codespaces it to ensure that the identifiers of instances of elements in an XML document are unique, even if they come from many different sources.

A ValidityCondition is used to attach conditions to elements to indicate when they are current or the circumstances in which they should be used (e.g. “In winter”). VALIDITY CONDITIONs can be attached to specific elements and also, through VERSION FRAMEs (see below), to whole sets of objects, so that it is possible to be precise about the conditions governing the coherence and relevance of data.

The DataManagedObject allows the assignment of a Version and responsibility attributes to an EntityInVersion and also one or more instances of a ValidityCondition.

EntityInVersion (Abstract)

A specific version of an ENTITY, as found in a NeTEx document. The NeTEx EntityInVersion implements ENTITY IN VERSION by adding VERSION tracking attributes and VALIDITY CONDITIONs (see later below) for any NeTEx element.

...

...

DataManagedObject (Abstract)

A DataManagedObject is a subclass of EntityInVersion that implements the common properties of all first-class NeTEx elements, such as:

  A ResponsibilitySet, specifying data management and stakeholder roles for the object.

A KeyList: an optional set of an arbitrary list of key/value pairs to provide a simple extensibility mechanism. KeyList will not be used in the European profile (however it remains available for local extensions).

An Extensions tag that allows the association of arbitrary user defined XML elements with an element. Extensions shall not be used within the European profile.

A reference to a Branding for the ENTITY to attribute a marketing content for presenting the element.

AlternativeText a set of alternative variants of any textual attribute of the ENTITY (the main purpose being translations into other national language).

DataManagedObject is an implementation artefact and does not appear in Transmodel.

...

...

KeyValue (Subcomponent of DataManagedObject)

A KeyValue is a convenient way to exchange additional specific data attributes not supported in NeTEx. Lists of values can be associated with any DataManagedObject. Note that the interpretation and use of each KeyValue requires an additional specification of its meaning by the local systems that use them.

In EPIP, extensions to elements will be based only on the Key/Value mechanism (i.e. the Extensions tag will not be used). Furthermore, KeyList shall not be used to carry information that can be encode elsewhere in NeTEx.

...

Example from the Austrian NeTEx Profile:

...

...

Version

NeTEx can support the exchange of data from systems with advanced versioning systems that track every change to every element - as recorded by a version attribute on DataManagedObject. However, many legacy systems do not support such versioning capabilities and so the provision of fine-grained tracking data in a NeTEx document is optional in EPIP. However frame level versioning is mandatory in EPIP.

In Transmodel, VERSIONs are themselves first class objects and can be given descriptions that explain the purpose and validity of the VERSION. These can be exchanged in NeTEx as Version instances.

In EPIP the Version element itself not populated; a simple version number in the version attribute of an EPIP element is used to indicate the version.

...

Codespace

A CODESPACE is similar to the XML concept of aNamespace that gives a context within which the names of elements and attributes in an XML schema shall unique, (using the generic W3C domain mechanism), thus permitting the combining of elements from different schemas in the same aggregated model. In a similar way, NeTEx uses Codespaces to ensure that the identifiers of instances of elements in an XML document are unique, even if they come from many different systems and are placed in the same document – see examples below. This allows data elements from different countries, different regions, and different organisations to be combined without clashes.

Having an explicit Codespace object also makes it possible for applications (such as a profile validator) to reflect on and compute over the elements within Codespaces in a generic manner (i.e. they can determine which coding system is being used for a given object and use this knowledge to inform the way they process data). The Codespace is thus used for three purposes:

...

In the context of EPIP, CODESPACEs prevent identifier clashes among data provisions coming from different countries (and regions, authorities and operators within countries. Different code structures may be used within different CODESPACES – see 8.4-Codespaces and the structure of identifiers for further discussion.

In order to manage a uniform coding system for use by many stakeholders, it may be desirable to partition a CODESPACE into different ADMINISTRATIVE ZONEs, based on spatial, modal or other criteria, each with a responsible ORGANISATION. Within the CODESPACE, the use of a specific prefix or prefix range value may then be reserved for the allocation of identifiers to new entities falling under the criteria of that zone. This allows the issuing of new codes to be delegated to the managers of the zone on a distributed basis. The central registrar function is needed only to setting up of the zones and issue the prefixes in the first place. ADMINISTRATIVE ZONES are not exchanged directly in the strict EPIP, but can be referenced with an external reference from a ResponsibilitySet (see 5.1.10)

A Codespace is specified as a path expression by using an internet domain, obtained through IANA (the Internet Assigned Numbers Authority), which provides a process for registering a domain as globally unique. For example, ‘http://tfl.gov.uk ’, ‘http://bahn.de ’, ‘http://ratp.fr ’, ‘http://foo.com ’, or ‘http://sbb.ch ’. The path can be declared in the <XmlnsUrl> attribute of a Codespace element.

Each Codespace has an associated prefix which may be used as a surrogate for the codespace throughout a document and is declared on a VersionFrame using a Codespace element. These prefixes provide an efficient way of encoding unique identifiers in an XML document in that the short prefix can establish a unique context for each identifier on every element id in a document (rather than say, a long qualifying string or complex code structure), even if the identifiers come from heterogenous coding systems. The prefix does not have to be the same as the id of the Codespace (For example, the examples in this document mostly use a prefix of ‘epd’ for the ‘epip_data’ Codespace and a prefix of ‘epip’ for the ‘epip_metadata’ Codespace. Technically the prefix is local to the document and different prefixes can be used for the same Codespace in different documents, but it is helpful to data consumers to use the same prefix values consistently.

...

                                     <Xmlns>napt</Xmlns>

                                     <XmlnsUrl>http://naptan.org.uk/naptan</XmlnsUrl>

                                     <Description>UK NaPTAN</Description>

...

                                     <XmlnsUrl>http://era.org.eu/stops</XmlnsUrl>

                                     <Description>European Rail Authority</Description>

...

               <StopPlaceid=”napt:4701234567”>

               <StopPlaceRefref=”napt:4701234567”>

               <StopPlaceid=”era:0018”>, etc.

An application processing a document is expected to understand any necessary rules peculiar to validating or interpreting the identifiers in a specific Codespace. For example, NaPTAN stop identifiers in the UK NAPTAN codespace have the structure ‘999 0 XXXXXXXXX’ where ‘999’ is an area prefix, ‘0’ is fixed and ‘XXXXXXXXX’ is a number unique within the area, whose length and nature depends on the mode of transport. An XML validator will not enforce the format rules, but an implementation that is aware of the CODESPACE and its rule system (as indicated by the domain url) is able to do so programmatically if it is relevant to do so (for example a system that is merely aggregating data to pass it onto others might be agnostic about the structure of identifiers). For the general purposes of emitting or parsing a NeTEx document, any such local rules are generally irrelevant; all that matters is that each entity instance can be uniquely identified.

...

Example from the Austrian NeTEx Profile:

...