datexii
commented
105 years ago Comment 87
Date: 1919-01-03 10:36:45 +0100 From: @ingeniumfaber
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.
This issue was created automatically with bugzilla2github.py
Bugzilla Bug 30
Date: 1919-01-03T10:36:44+01:00 From: @ingeniumfaber To: @JosefKaltwasser CC: @iancornwellmottmac
Last updated: 2021-04-21T12:23:11+02:00