Home » railML newsgroups » railml.common » [railML3] Extension methods (Should we consider other ways to extend railML?)
[railML3] Extension methods [message #2088] Fri, 11 January 2019 17:01 Go to next message
Thomas Nygreen JBD is currently offline  Thomas Nygreen JBD
Messages: 68
Registered: February 2017
Dear all,

Apologies for flooding the forum recently, but these are exciting times and there are so many interesting things to discuss.

On page 9 of Christian's slides provided in the modelling patterns thread the "any" extension points are presented. We also know these from railML 2. The effect of these extension points is the flexibility that when a use case arises that is not fully covered by railML, one can create new attributes and elements that can be used at any of these extension points.

In the same thread, Jörg and I briefly touched upon differences between subschemas in the availability of these extension points, but the topic I want to raise here is how these extension points are used.

The complete flexibility of these extension points is both a strength and a weakness. They make it possible to define a new global attribute that can be used on all elements with the anyAttribute extension point. The downside is that it is not possible (with plain XSD 1.0) to restrict where an extension attribute or element can be placed. If needed, this has to be done by formulating rules that are checked through separate routines. One relevant standard for this is Schematron.

The discussion on polymorphism inside railML got me thinking about extensions through polymorphism. In an extension schema it is fully possible to extend a railML complexType to add new attributes. Then, the xsi:type of the standard railML element can be set to this new extended type to include the new attributes. An example:

In railML2.4nor, which uses the extension points provided in railML 2.4, there is a new attribute nor:mounted (I will use the nor: prefix for this extension namespace). This attribute is intended as an extension for the railML element <signal> to describe if the signal is mounted on a pole or gantry. However, there is no technical barrier available to restrict where this attribute is used, so using it on any other element with the anyAttribute extension point will not cause any validation errors. This is not necessarily a problem if we assume that users of this extension apply common sense and read the extension documentation. A use case can also appear where it is useful to use the same attribute on other elements as well. Also, this approach makes it easy to combine multiple extension schemas that were developed independently.

An alternative implementation would be to create a new complexType (e.g. nor:signal) that extends tSignal and adds new attributes such as mounted. To use these new attributes the type of the <signal> element must be recasted by setting it explicitly to the extended type: <signal xsi:type="nor:signal" ... mounted="pole"/>. The strength of this approach is that it does control where the extensions can be used. In this example the mounted attribute can only be used on the signal element and only when xsi:type of that signal is set to nor:signal. The weaknesses are that each element type has to be extended to apply the same attribute to multiple elements, and that it is more complex to combine extensions. If two different extensions are used together, and they both provide a type extending the signal element, one must choose one of the types, or one schema must base its extension on the other.

It is also possible to combine the two approaches. This reduces the problem of colliding extensions. For technical reasons it is however not possible to add new subelements in an extended type if the original element type contains the any element extension point. For the same technical reasons this problem does not apply to attributes.

The extensions I know (TPS and railML2.4nor) both use the provided extension points and no recasting of elements. For railML2.4nor we have discussed but not yet implemented an extra layer of validation in Schematron.

What are the opinions on extending by recasting (i.e. xsi:type)? Should this be allowed, or even encouraged?

Best regards,
Thomas Nygreen
Railway capacity engineer

[Updated on: Fri, 01 October 2021 16:50]

Report message to a moderator

Re: [railML3] Extension methods [message #2861 is a reply to message #2088] Thu, 09 December 2021 16:58 Go to previous message
Milan Wölke is currently offline  Milan Wölke
Messages: 87
Registered: April 2007
Hi Thomas,

I meant to reply to this for a long time already. And after you brought it up again during the conference in Sweden, I feel I should add my position on this.
From my point of view we should switch over to the xsi:type based approach of extending existing railML modelling in railML 3. My reasoning would be that it is otherwise impossible to generate code for an extension. This may actually be fine for minimalistic extensions, but for anything that is a bit more complex, I think that it's a necessity. Even when not using code generation it has advantages as like this documents can be validated.
I do not agree with the weakness you see with this approach regarding the fact that you need to specify it more than once like this. It is true, you need to specify it for all the places you need an extension. But you also need to implement it as an exporter and an importer at the same places anyway. Like this at least you can be sure that it either is specified or not.


Best regards, Milan

Milan Wölke - Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Previous Topic: [railML2/3] creating a new element to describe the project metadata
Next Topic: Possession Mgmt Use-Case
Goto Forum:

Current Time: Thu Jan 27 13:19:07 CET 2022