Restriction on generalisation across Level A / extension boundary - consider or clarify implication

Submitted by iancornwell on Friday, 25 August, 2017 - 11:48
Issue ID
Feature request

There are 2 different kinds of generalisation allowed in DATEX: - Generalisation across the boundary between the core (“level A”) DATEX model and an extension model - Other inheritance i.e. between 2 concepts within the core, or between 2 concepts within extensions In the former case DATEX specifications insist that a DATEX “level B extension” mechanism is used (clause 8.2.6 in prEN 16157-1). But only in the latter case does the specialised subclass inherit the attributes of the superclass. Some extension authors may want to specialise a core DATEX class, but only to use the specialised class directly in the extension model, not for the purpose of allowing the specialised class to be used in place of the original core superclass where that core superclass is used in the core Level A model. (The UTMC suppliers in the UK actually did this - they produced an extension model where core Fault was specialised by TrafficSignalFault, but where the only intended use of TrafficSignalFault was in an aggregated property of another class in the extension.) To get the intended effect, the generalisation would have to NOT be a <>, but the DATEX specification says that is not allowed. This is intentional, to preserve the backwards compatibility guarantee. The risk of allowing normal inheritance across the core/extension boundary is that even although there may be no intention by the extension author to allow the specialised class in place of a superclass where the superclass is used in the core Level A model, some other user of the extension model could try to do that because they see the inheritance relationship, and then IF they also sent this data through level A software that was unaware of the extension, it would not validate. Which is more important: the inconvenience of not being able to use regular inheritance across the boundary, or the risk to backwards compatibility? Given that extension authors have a workaround of changing generalisation to composition, the current position is not unreasonable, but given that the full implication of the methodology was initially missed by the UTMC group, it seems helpful if we could add a little additional explanatory material to the methodology specification to supplement 8.2.6, to point out explicitly that since regular inheritance across the boundary is not permitted, a logical specialisation in the domain would be modelled by composition in this case.

{"changeLogs":[{"date":1528364085727,"componentOLD":"- Select a value -","component":"Methodology","categoryOLD":"- Select a value -","category":"Feature request","priorityOLD":"- None -","priority":"Normal","assignedOLD":"","assigned":"Josef Kaltwasser (18)","statusOLD":"- None -","status":"Active"},{"date":1537267130971}]}

Posted by iancornwell on February 23, 2021 Permalink

The issue description text contained the stereotype name "D2LevelBExtension" in the sentence starting "To get the intended effect" but it is missing in the visible output, presumably due to use of the chevron symbols.

Posted by Josef Kaltwasser on January 23, 2021 Permalink

Using normal UML Generalizsation across the border between Level A and extension will be allowed in v3.0 by changing clauses 8.2.6/9/11. Users shall be made aware that instances of such classes can not be used in a polymorphic way . It shall also be mentioned that it is not possible to combine bot Generalization methods.

Posted by Josef Kaltwasser on June 23, 2020 Permalink

The fix announced in comment #3 has obviously not been properly incorporated in the version of prEN 16157-1 delivered to CCMC. Hence, I have re-opended the issue