Home » railML newsgroups » railml.common » Issue with unique tID in commons3
Issue with unique tID in commons3 [message #3045] Wed, 18 January 2023 15:27
marklorenz(at)thalesgroupc is currently offline  marklorenz(at)thalesgroupc
Messages: 1
Registered: January 2023
Junior Member

For all of you not knowing me: I am Mark from Thales. Usually, I try to participate at the TT workgroup.


Recently we faced bug here regarding unique IDs:

commons3.xsd defines tID as follows:

<xs:simpleType name="tID">
  <xs:union memberTypes="rail3:tGenericID rail3:tUUID"/>

Means a tID can be either of type tGenericID or tUUID. Internally, tGenericID is correctly classified as "unique" and is fine. tUUID, on the other hand, is not "unique". Thus, depending on the interpretation, tID can be sometimes unique and sometimes not. Depending on which type the value is assigned to.

In our system the JAXB parser seems to work as follows:

- If an ID starts with a letter, it becomes a tGenericID (which is funny, because "a8986caf-b0d1-32ca-b1a9-09f86213da2f" is pretty sure an UUID) and is therefore unique (because upper element xs:ID is unique by definition).
- If an ID starts with a digit, it becomes a tUUID ("68986caf-b0d1-32ca-b1a9-09f86213da2f") and therefore doesn't have to be unique anymore.

Why JAXB works in such a funny way is up to the user. But there is clearly a lack of consistency for the type tID. Ideally, tID should be unique, because otherwise you can't really talk about IDs, can you?

We implemented a quick-and-dirty workaround to satisfy JAXB, but maybe you can look over it to find a proper solution?

Greetings Mark

[Updated on: Wed, 18 January 2023 15:29]

Report message to a moderator

Previous Topic: [railML3] Binding position of Meta-Data in railML-Scheme
Goto Forum:

Current Time: Fri Jan 27 12:19:38 CET 2023