|
Re: [railML3] How to deal with UUIDs [message #3287 is a reply to message #3280] |
Thu, 29 August 2024 12:26 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
Christian Rößiger
Messages: 63 Registered: March 2015
|
Member |
|
|
Hello everyone,
Firstly, I would like to say that I have not used UUIDs so far and therefore have not thought in detail about how I would integrate them within a railML data exchange. If we need references to data outside the railML file, we use the designator element or equivalent(train number, ...)
However, from my experience as a developer of a railML import interface for timetable data, I would say that a distinction between UUID/Xml-Id on the reference side would be more important to me than with the Ids: When I parse a railML file and come to a reference, I need to know whether I have to search for the corresponding Id within the railML file or in some external repository/database.
I also find it helpful that standard XML parsers can check whether there is an ID for each XML reference in the railML file. If the distinction between UUID/Xml-Id is only implemented in one place (id _or_ reference), this possibility would probably no longer exist.
For these reasons, I would be prefer to explicitly distinguish between UUID/Xml-Id at least at the reference location, or better in both places.
Best regards
Christian Rößiger
--
iRFP e. K. · Institut für Regional- und Fernverkehrsplanung
Hochschulstr. 45, 01069 Dresden
Tel. +49 351 4706819 · Fax. +49 351 4768190 · www.irfp.de
Registergericht: Amtsgericht Dresden, HRA 9347
[Updated on: Thu, 29 August 2024 12:26] Report message to a moderator
|
|
|
Re: [railML3] How to deal with UUIDs [message #3288 is a reply to message #3280] |
Thu, 29 August 2024 15:27 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) |
David Lichti
Messages: 17 Registered: December 2020
|
Junior Member |
|
|
I agree with Christian on removing the tUUID type from the unions in tRef and tID. It removes ambiguity from the data.
But I would even question the general introduction of a replacement attribute for tUUID, as I don't see the generic utility of such an identifier.
For references within one export file, the tID type is very well suited.
For references between different exports, the dentifiers must not only be unique, but also stable. For tools that do not store their data in railML format (as is the case for our TPS), it would be necessary to maintain a mapping between the internal object identifiers, and the railML identifiers. In general, this may be an m-to-n relationship, since the two data schemas may have different structures. Maintaining such a mapping does not really seem practical.
We use specific business keys for objects that need common and stable identifiers for references to and from external systems. But these identifiers and their format are usually defined by external entities. Most often, they do not match the tUUID pattern. The designator type is much more suited for these identifiers.
In conclusion, I suggest
1. Removing the tUUID type from the unions in tID and tRef to make the schema less ambiguous.
2. Adding a generic entry UUID to the register code list as a replacement for tUUID.
3. Adding designator elements wherever there is a specific need for external references.
Best regards
David
|
|
|