Dev:identities: Difference between revisions

From railML 2 Wiki
Jump to navigation Jump to search
[checked revision][checked revision]
m (Ferri Leberl moved page CO:identities to Dev:identities: Vereinheitlichung)
Line 46: Line 46:


=== Wrong style ===
=== Wrong style ===
 
{{note|If the semantic information is not separated, the importing software has to parse the {{Attr|id}} value in order to use it.
If the semantic information is not separated, the importing software has to parse the {{Attr|id}} value in order to use it.


<pre><formation id="fTGV-ICE3">...</pre>
<pre><formation id="fTGV-ICE3">...</pre>


This coding style hinders interoperability!
This coding style hinders interoperability!
 
|error}}
Please use a generic coding style for the {{Attr|id}} value. Look for appropriate railML attributes in the element and put the semantics there. Otherwise use the [[CO:usingAny#New_attributes_.28Use_of_xs:anyAttribute.29|xs:anyAttribute mechanism]].
Please use a generic coding style for the {{Attr|id}} value. Look for appropriate railML attributes in the element and put the semantics there. Otherwise use the [[CO:usingAny#New_attributes_.28Use_of_xs:anyAttribute.29|xs:anyAttribute mechanism]].



Revision as of 16:04, 30 May 2018

railML Identities

Very much railML elements require an id attribute of the W3C-Type xs:ID.

This has to be provided in order to enable references, that are very much used within the railML schemas.

On the other hand, software tools may refer to certain railML elements, that are not referred to within the railML file.

Semantics

The general railML description states the following semantics for this attribute.

  • id: XML-file-wide unique, machine-interpretable identity, required for later referencing that element internally. For a detailed explanation see Dev:identities.
    XML-Datei-weit eindeutige, maschineninterpretierbare Identität, die für die spätere interne Referenzierung dieses Elements erforderlich ist. Für eine detaillierte Erklärung siehe Dev:identities.

Constraints

The general railML description states the following contraints.

  • id: xs:ID, required
    a string, starting with a letter (a..zA..Z) or an underscore (_),
    followed by a non-colonized and non-spaced string consisting of letters, digits, points (.), dashes (-) or underscores (_)

Export of railML files

Software tools, which create railML files, are free to define id values according to the above mentioned constraints.

Recommendation

railML recommends using generic values, e.g.

<formation id="d2e717" name="TGV-ICE3">...

or serial numbers with letter prefixes, e.g.

<formation id="rsf0002" name="TGV-ICE3">...

Bad style

Sometimes exporting software tools create id values, that contain semantic data, like train numbers or vehicle family codes.

Only if this semantic information is repeated in separate attributes of the same element, the importing software is not required to parse this id value.

<formation id="fTGV-ICE3" name="TGV-ICE3">...

Please use some more generic coding style in order to not invite the importing software to parse the id values!

Wrong style

If the semantic information is not separated, the importing software has to parse the id value in order to use it.
<formation id="fTGV-ICE3">...

This coding style hinders interoperability!

Please use a generic coding style for the id value. Look for appropriate railML attributes in the element and put the semantics there. Otherwise use the xs:anyAttribute mechanism.

Import of railML files

Recommendation

Software tools, which consume railML files, should take the id values only for referencing issues.

In case of valid railML files, no problems will occur.

Good style

In case of consuming "good or bad styled" id values the importing software provides routines for getting the semantics from better fitting attributes.

In case of consuming "wrong styled" id values the importing software is required to parse the attribute content for getting the semantics.

That way, the most robust import interface is assured.

Wrong style

The importing software expects to parse the id value with a special regular expression in order to get the coded semantics.

That way, "good styled" id values can't be imported!