Forum - RDF feed
https://www.railml.org/forum/index.php
References across several XML files
https://www.railml.org/forum/index.php?t=rview&goto=2173&th=657#msg_2173
during the conference in Linz the question about references in railML3.x was
raised. Currently the referencing in IS-IL is using the ID/IDREF mechanism of
XML or alternatively UUIDs. At least the first option can be validated only,
when reference and target are within the same XML file. However, in future
scenarios only parts of the information will be exchanged, e.g. a new timetable
will not repeat the complete infrastructure but needs referencing into it.
Thus the option of using the <designator> element available at
FunctionalInfrastructureEntity and EntityIL instead. When using an official
register the name shall be unique in the register. However, it may appear at
least twice when used for IS part and IL part, e.g. signalIS/designator and
signalIL/designator.
There is another issue with using designator as it has two mandatory attributes
@register and @entry. Thus a reference to designator shall be always contain the
complete tuple of @register and @entry to be unambiguous.
What is your opinion on the topic of references?
--
Best regards,
Joerg v. Lingen - Interlocking Coordinator]]>Jörg von Lingen2019-04-13T02:12:57-00:00Re: References across several XML files
https://www.railml.org/forum/index.php?t=rview&goto=2175&th=657#msg_2175
dear all,
I believe that the inclusion of UUIDs as possible IDs and references and the general application of the designator concept are important improvements in railML 3.1 over railML 2.x. Furthermore I believe we should establish a best practice on when and how to use which method. I will add some more thoughts on that after Easter. I encourage the community to post yout views on Jörg's question.
Best regards,
Thomas Nygreen - Common coordinator]]>Thomas Nygreen JBD2019-04-15T21:35:53-00:00Re: [railML3] References across several XML files
https://www.railml.org/forum/index.php?t=rview&goto=2180&th=657#msg_2180
Am 13.04.2019 um 04:12 schrieb Joerg von Lingen:
> [...] What is your opinion on the topic of references?
I think that we have to distinguish different types of references:
(1) references that are used only inside one railML file
(2) references from inside a file to "something" outside
(3) references from "something" outside to an element inside a file
For (1), ID/IDREF seems to be the best solution, because an XML scheme
validator can check for corrupt references (e.g. missing destinations or
double IDs).
For (2) and (3), we need "external IDs" and "external references". I
propose to define new attributes of type xs:string in order to allow for
any kind of ID or reference. Using UUIDs or GUIDs might be helpful (e.g.
when adressing data stored in data bases), but there are also cases,
where the external ID or reference shall be very simple.
Following this approach the railML model need to be modified only a
little bit:
* ID can remain like it is today
* apart from the IDREF based reference, a new (external) reference of
type xs:string shall be added.
You may ask: why don't you use the <designator>?
My answer: an element shall have only on ID that can be used for
adressing the element, but it may have an arbitrary number of
designators in different registers.
Best regards
Christian
--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org]]>christian.rahmig2019-04-16T18:52:25-00:00Re: [railML3] References across several XML files
https://www.railml.org/forum/index.php?t=rview&goto=2199&th=657#msg_2199
Christian did made the proposal to add a new attribute/element used in case of external references. I would not like
this approach as it would mean we have *two* possible places to look for 'id' and 'references'.
In case both opprotunies used, who will decide which one shall prevail?
--
Best regards,
Joerg v. Lingen - Interlocking Coordinator
Christian Rahmig wrote on 16.04.2019 20:52:
> Following this approach the railML model need to be modified only a
> little bit:
> * ID can remain like it is today
> * apart from the IDREF based reference, a new (external) reference of
> type xs:string shall be added.]]>Joerg von Lingen2019-05-31T11:12:01-00:00Re: [railML3] References across several XML files
https://www.railml.org/forum/index.php?t=rview&goto=2203&th=657#msg_2203
I agree with Jörg that there should be only one place to define references and IDs. I think we will not always know beforehand whether a reference will be of type 1, 2 or 3. It will be different in different applications.
My suggestion would be to expand the pattern of tID and tRef. They are currently defined as unions, allowing either a UUID or an xs:ID/xs:IDREF. With a third option of type xs:string, we would cover all options.
I guess a problem could then be that a misspelled UUID or an unmatched IDREF would slip through the XML validation by being identified as a string? So there would in effect be no type check at all. But that can also be seen as a consequence of allowing external references - we can not rely on the XML parser to validate the references anymore.
As you can see, this suggestion is rather incomplete. I hope someone else will pick up the thread!
Best Regards,
Martin
]]>Martin Karlsson2019-06-10T12:32:50-00:00Re: [railML3] References across several XML files
https://www.railml.org/forum/index.php?t=rview&goto=2245&th=657#msg_2245
I put the (so far collected) conclusions of this discussion into a Trac
ticket [1]. Please let us know if something is missing.
--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org]]>christian.rahmig2019-09-02T10:39:47-00:00Re: [railML3] References across several XML files
https://www.railml.org/forum/index.php?t=rview&goto=2257&th=657#msg_2257
I see similarities with how references are constructed in the XMI specification, which could be seen as an example of a mature format.
I am referring to the XMI specification:
For example see https://www.omg.org/spec/XMI/ISO/19509/PDF and sections about element identification and linking.