Home » railML newsgroups » railML.infrastructure » [railML3] Proposal for removing "any" elements (this post just points to another post where the proposal is presented)
[railML3] Proposal for removing "any" elements [message #2972] Tue, 22 March 2022 09:13 Go to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 447
Registered: January 2016
Senior Member
Dear railML IS community,

At our last conference in Gothenburg, Sweden, our Common Coordinator raised the issue of changing the way extensions for railML can be created in railML3. Thomas presented a new approach there, which is, however, mutually exclusive with the current approach. He has created a forum post on this, which unfortunately has not received much attention so far:

https://www.railml.org/forum/index.php?t=msg&th=638& start=0&

The railML.org coordinators think it is a good idea to use this new technique, as it allows, among other things, to validate documents with custom extensions of the respective railML interfaces. However, since such a change will mean that existing extensions will no longer work with a new railML version, we need your feedback to check whether the advantages we see in the new way are convincing to you as well. Please let us know what you think under the thread above.

Background:

Previously, the common practice was to provide extension points in the official railML schema. This allowed an XML that contained non-railML tags at such a point to still be considered valid railML. The disadvantage of this approach is that it is not possible to specify through the extension schema itself where these non-railML tags are allowed and where they are not. An extension that is intended to record opening hours for a station building could thus also be used to record opening hours for a circulation or for a train number. From a technical point of view, this does not make sense. With the extension points it is not possible to restrict this. With the newly proposed approach (see forum post) this would no longer be a problem. In addition, code generation tools could also be used to implement code for importing and exporting railML more efficiently.

We therefore propose to replace the extension points with railML 3.2 with the new inheritance method. Please let us know at the link above whether there are any professional/technical arguments against this from your point of view.

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML3] Proposal for removing "any" elements [message #3016 is a reply to message #2972] Tue, 14 June 2022 10:38 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 447
Registered: January 2016
Senior Member
Dear all,

as you may have noticed, railML 3.2 comes along with a new approach for modelling schema extensions based on xsi:type as introduced with the previous forum post. In order to better understand the usage of xsi:type the wiki page [1] has been set up to describe the extension concept with a practical example.

[1] https://wiki3.railml.org/wiki/Dev:Using_xsi:type

Best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML3] Proposal for removing "any" elements [message #3024 is a reply to message #3016] Mon, 04 July 2022 14:16 Go to previous messageGo to next message
Jörgen Strandberg is currently offline  Jörgen Strandberg
Messages: 15
Registered: August 2017
Junior Member
Hi,
The example of how to define and use the extension concept to represent data seems reasonable.

As a tool vendor, I still have a doubt about how to support the extension concept when parsing.
This specifically when xsi:type defines an unknown subclass of a standard railML type.

The railML parser we are developing is generated by and based on the Eclipse Modeling Framework (EMF). It will not, out of the box, support unknown subclasses.
EMF provides a pattern for handling unknown elements/attributes, which could be a part of the solution. But I would rather not have to resort to it because of the additional implementation effort.

Is there already a standard mechanism or concept of XML parsers that can be used to ignore any unknown xsi:type values, but still read all attribute values of the standard railML type?
Re: [railML3] Proposal for removing "any" elements [message #3025 is a reply to message #3024] Mon, 04 July 2022 16:20 Go to previous messageGo to next message
Milan Wölke is currently offline  Milan Wölke
Messages: 142
Registered: April 2007
Senior Member
Hi Jörgen,

sorry, but I havent had much experience with the EMF so far. So what you are saying is that the EMF will completely skip unknown subclasses of known ones if encountered during parsing? Do you evaluate a xsi:schemaLocation included in the document? Im asking because other generated parsers in the case you are describing fall back to the known base class.

Best regards, Milan


Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML3] Proposal for removing "any" elements [message #3052 is a reply to message #3025] Mon, 13 February 2023 09:39 Go to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 447
Registered: January 2016
Senior Member
Dear Jorgen,

since there was no further feedback on the questions of Milan I assume that you have solved the problem with handling xsi:type extensions in EMF? If so, could you share your experiences with us so that we can learn something from this?

Thank you very much and best regards
Christian


Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Previous Topic: [railML3] LevelCrossing Best Practice Example
Next Topic: [railML 2] Semantic Constraint at trackBegin and trackEnd
Goto Forum:
  


Current Time: Mon Jul 15 11:02:03 CEST 2024