Inconsistncy between Methdololgy and tool/generated schema

Submitted by Josef Kaltwasser on Tuesday, 24 August, 2010 - 11:43
Issue ID
Bug report

I've allocated this bug report to the tool but the choice is arbitrary. It can also be assigned to the methodology. The bug refers to a contradiction between the rules for schema mapping of extensions as described in section 4.6 of the methodology document and what the tool does in reality.

Section 4.6 states:
In these cases, the specialisation is not mapped to an extension, but the extension element of the superclass is replaced by an XML element of the same name that is of an anonymous complex type which consists of a sequence of XML elements that represent the – potentially – multiple classes that extend this superclass in the extensions.

This means that

  <xs:element name="someClassExtension" type="D2LogicalModel:ExtensionType" minOccurs="0" />

is replaced by

   <xs:element name="someClassExtension">
            <xs:element name="classA" type="D2LogicalModel:ClassA"/>
            <xs:element name="classB" type="D2LogicalModel:ClassB"/

The tool actually does not create the anonymous type but creates an internal type called "_SomeClassExtensionType". The type of the someClassExtension element is then switched to this new type.

The internal type contains an element with identical name as the extension class. It is worth noting that this is the only part of the specification where lexicographically identical names are used for different things and that it seems to vialoate the convention that element names should be transformed from UCC to LCC notation. It looks as if this was not intentional, so even if htis bug should be shifted to methodology, the naming convention in the tool should be revised.

I copy in an example from a level B extension I made on TrafficSpeed:

  <xs:complexType name="_TrafficSpeedExtensionType">
      <xs:element name="TrafficSpeedExtended" type="D2LogicalModel:TrafficSpeedExtended" minOccurs="0" />
      <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded" />


{"changeLogs":[{"date":1528112937469,"statusOLD":"- None -","status":"Fixed","assignedOLD":"","assigned":"Unassigned","priorityOLD":"- None -","priority":"Normal","categoryOLD":"- Select a value -","category":"Bug report","componentOLD":"- Select a value -","component":"Tool"},{"date":1528112985918,"assignedOLD":"Unassigned","assigned":"Josef Kaltwasser (18)"},{"date":1528114778456,"assignedOLD":"Josef Kaltwasser (18)","assigned":"jaderberg (22)"},{"date":1537270702823}]}

Posted by jaderberg on August 25, 2028 Permalink

Yes, I think it was afetr the Vienna meetingwe decided that all classes generated by the tool should begin with a underscore. This is a bug in the methodology.

Yes, the naming of the element should have been in LCC. I call it a bug in the tool.

Posted by jaderberg on August 25, 2028 Permalink

After some investigation, I have found that extensions have never been implemented as an anonymous types. I have checked version 1.0 and even there the extension are generated in the same way as today.

The only thing that has changed regarding the extension is the decision to name all internal classes/complexTypes be prefixed with a _. This to avoid naming conflicts.