ScheduledStopPoint is restricted in such way, that it cannot fullfill its identity constraints

[skinkie]

While developing the ultimate correct class interpretation for NeTEx I have stumbled via #526 on a situation where my more valid interpretation now shows that there are huge bugs in the NeTEx XML Schema. I have asked @ue71603 to verify.

Lets take a look at ScheduledStopPoint. The restriction restricts the elements and attributes to the provided group and only the id-attribute. is valid.

        <xsd:element name="ScheduledStopPoint" abstract="false" substitutionGroup="Point_">
                <xsd:annotation>
                        <xsd:documentation> A POINT where passengers can board or alight from vehicles. It is open, which hierarchical level such a point has. It can represent a single door (BoardingPosition) or a whole ZONE. The association to the physical model is done with STOP ASSIGNMENTs.</xsd:documentation>
                </xsd:annotation>
                <xsd:complexType>
                        <xsd:complexContent>
                                <xsd:restriction base="ScheduledStopPoint_VersionStructure">
                                        <xsd:sequence>
                                                <xsd:sequence>
                                                        <xsd:group ref="EntityInVersionGroup" minOccurs="0"/>
                                                </xsd:sequence>
                                                <xsd:sequence>
                                                        <xsd:group ref="DataManagedObjectGroup"/>
                                                </xsd:sequence>
                                                <xsd:sequence>
                                                        <xsd:group ref="PointGroup"/>
                                                </xsd:sequence>
                                                <xsd:sequence>
                                                        <xsd:group ref="TimingPointGroup"/>
                                                </xsd:sequence>
                                                <xsd:sequence>
                                                        <xsd:group ref="ScheduledStopPointGroup"/>
                                                </xsd:sequence>
                                        </xsd:sequence>
                                        <xsd:attribute name="id" type="ScheduledStopPointIdType" use="required"/>
                                </xsd:restriction>
                        </xsd:complexContent>
                </xsd:complexType>
        </xsd:element>

XML Spy agrees with this interpretation (thanks @ue71603)

If we look at the ScheduledStopPoint key it should at least consists of an id and version attribute.

                <!-- =====ScheduledStopPoint Key ========================== -->
                <xsd:keyref name="ScheduledStopPoint_KeyRef" refer="netex:ScheduledStopPoint_AnyVersionedKey">
                        <xsd:selector xpath=".//netex:ScheduledStopPointRef | .//netex:ServiceLink/netex:FromPointRef | .//netex:ServiceLink/netex:ToPointRef | .//netex:FromStopPointRef | .//netex:ToStopPointRef | .//netex:NextStopPointRef | .//netex:AtStopPointRef | .//netex:StartStopPointRef | .//netex:EndStopPointRef | .//netex:FareScheduledStopPointRef | .//netex:AccountingStopPointRef | .//netex:AdjacentStopPointRef"/>
                        <xsd:field xpath="@ref"/>
                        <xsd:field xpath="@version"/>
                </xsd:keyref>
                <xsd:key name="ScheduledStopPoint_AnyVersionedKey">
                        <xsd:selector xpath=".//netex:ScheduledStopPoint | .//netex:FareScheduledStopPoint"/>
                        <xsd:field xpath="@id"/>
                        <xsd:field xpath="@version"/>
                </xsd:key>

Never the less, the way this is behavior is invisible to many (if not all) code generator utilities because they can't restrict a childs inherited attributes to 'null', I know that many, if not all profiles have an interpretation not matching what is actually written in the standard.

[Aurige]

What do you see as bug here ? I don't see why ScheduledStopPoint cannot fullfill its identity constraints

[skinkie]

@Aurige a version attribute is referenced as compound key with the id attribute. The version attribute is not part of the restriction, therefore excluded.

[Aurige]

are you sure ? we are using version all over without issues .. looking at the #529 I think that restrictions don't behave the same way on attributes and elements: not mentioning them for attributes does not "remove" them (as it does for elements), but mentioning them allow to specialise them (typically used to specialise the type in NeTEx). Let's discuss this with @nick-knowles during next meeting.

[skinkie]

@Aurige look at your marvel XML Spy output. The attribute version is grayed out.

[Aurige]

yes, but you can still instantiate it as in most of the examples ... it looks like for attributes greyed out in the restriction only means "not specialised"

[hilcokats]

O'Reilly suggests @Aurige is right about restrictions working differently for attributes and elements: "(...) The only exception is attributes whose description may be skipped under xs:restriction, if not changed."

[skinkie]

I have fixed it in my generation prototype, thanks all and specially @hilcokats for these insights.