Home » railML newsgroups » railml.common » [railML3] How to deal with UUIDs (Creating a new attribute for UUIDs)
[railML3] How to deal with UUIDs [message #3280] Thu, 22 August 2024 12:39 Go to next message
Larissa Zhuchyi is currently offline  Larissa Zhuchyi
Messages: 43
Registered: November 2022
Member
Dear all

Following an issue [1] and a poll from the conference [2] in railML 3.3 railML.org is going to create a new attribute for specifying UUIDs and remove the union from the id type.

This is justified because of:
- validation issues;
- programming problems with type unions;
- understanding what user has when having a union in id attribute (is it a UUID or an XML id).

Please let us know if you have anything against adding the new UUID attribute and answer the following questions:

1) Should the references should also be split?
2) Should this be included in railML 3.3 or railML.org waits till railML 3.4?

Proposal: railML.org could only split the id and leave the ref as is.

For context see also [3, 4 5].

[1] https://development.railml.org/railml/version3/-/issues/560
[2] https://www.railml.org/en/event-reader/44th-railml-conferenc e-rome.html?file=files/download/events/conferences/railml_44 th_Rome/2023-11-08_railML_Nygreen_CommonNewsAndQuestions.pdf &cid=11491
[3] https://www.railml.org/forum/index.php?t=msg&goto=3045
[4] https://www.railml.org/forum/index.php?t=msg&goto=2203
[5] https://www.railml.org/forum/index.php?t=msg&goto=1315

Sincerely,

Larissa Zhuchyi – Ontology Researcher
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

[Updated on: Thu, 22 August 2024 13:16]

Report message to a moderator

Re: [railML3] How to deal with UUIDs [message #3287 is a reply to message #3280] Thu, 29 August 2024 12:26 Go to previous messageGo to next message
Christian Rößiger is currently offline  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
David Lichti is currently offline  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

Report message to a moderator

Previous Topic: Use railML to model parts of a large network
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Sun Sep 01 09:23:28 CEST 2024