| [railML3] Proposal for removing "any" elements [message #2972] |
Tue, 22 March 2022 09:13  |
christian.rahmig
Messages: 458
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  |
christian.rahmig
Messages: 458
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 #3025 is a reply to message #3024] |
Mon, 04 July 2022 16:20 |
Milan Wölke
Messages: 145
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 |
christian.rahmig
Messages: 458
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
|
|
|
|
Members
Search
Help
Login
Home
