-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"RefStructure" generic variant (VersionOfObjectRef) #407
Comments
Just to clearly understand your expectation, for example we have but also
So the InfrastructureLinkRef is both inheriting from LinkRefStructure and is in the LinkRef substitution group (that allows interchageability of elements with less contraints than the inheritance, which is sometimes necessary (for example due to some multiple inheritance in TM). So this has been adopted as a kind of design pattern for all Refs in NeTEx. What would you like to change here ? |
What is missing from these elements is that they never inherit from VersionOfObjectRef. If they would, it is extremely clear that they are in fact a group of objects that are references (and can be treated as such). |
in that case, they do since you also have:
So the inheritance chain is InfrastructureLinkRefStructure -> LinkRefStructure -> VersionOfObjectRefStructure |
Restriction base is not used for all the other RefObjects... |
An example. Why not base the top object on VersionOfObjectRef? <xsd:element name="SomethingElseRef" type="SomethingElseRefStructure" substitutionGroup="VersionOfObjectRef"> |
that's for strong typing, and avoid mixing refs of totally unrelated types of objects. |
Lets start with the first example. Your argument would be: "It has a restriction base". Can you elaborate what the technical difference would be between the restriction base or it being a substitutiongroup? <xsd:complexType name="AccessEquipmentRefStructure">
<xsd:annotation>
<xsd:documentation>Type for a reference to an ACCESS EQUIPMENT.</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:restriction base="PlaceEquipmentRefStructure">
<xsd:attribute name="ref" type="AccessEquipmentIdType" use="required">
<xsd:annotation>
<xsd:documentation>Identifier of a ACCESS EQUIPMENT.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType> <xsd:complexType name="PlaceEquipmentRefStructure" abstract="true">
<xsd:annotation>
<xsd:documentation>Type for a reference to an PLACE EQUIPMENT.</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:restriction base="InstalledEquipmentRefStructure">
<xsd:attribute name="ref" type="PlaceEquipmentIdType" use="required">
<xsd:annotation>
<xsd:documentation>Identifier of a PLACE EQUIPMENT.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType> <xsd:complexType name="InstalledEquipmentRefStructure" abstract="true">
<xsd:annotation>
<xsd:documentation>Type for a reference to an INSTALLED EQUIPMENT.</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:restriction base="EquipmentRefStructure">
<xsd:attribute name="ref" type="InstalledEquipmentIdType" use="required">
<xsd:annotation>
<xsd:documentation>Identifier of an INSTALLED EQUIPMENT.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType> <xsd:complexType name="EquipmentRefStructure">
<xsd:annotation>
<xsd:documentation>Type for a reference to an EQUIPMENT.</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:restriction base="VersionOfObjectRefStructure">
<xsd:attribute name="ref" type="EquipmentIdType" use="required">
<xsd:annotation>
<xsd:documentation>Identifier of an EQUIPMENT.</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType> |
One wants a structure hierarched for the xxxRefs so one can reference all the subtypes of a supertype with a sing ref to the supertype XML has some pretty horrible limitations and complexities on restricting / extending types and elements (and there are several of weird bugs in XMLSpy on validating) . _ |
@skinkie What do we do for 2.0? Or is this a general 2.1 subject? |
I hope we can this as a hygiene improvement in 2.0. |
@skinkie to check with some of above examples ... and generalise if OK |
At this point there are about 426 "*RefStructure" variants which model about the same attributes, some with marginal differences for example having the ref as a mandatory attribute. I would like to understand why this was not done via the SubstitutionGroup VersionOfObjectRef? Can we try to model this in NeTEx 2.0?
This would be my list of "issues".
The text was updated successfully, but these errors were encountered: