1
votes

Aim: In my project, the data preparation is done in different levels by different teams. The format we use for data preparation is XML. To support the above needs, we have prepared the XSDs with different layers(different target namespaces) and each XSD layer will inherit the previous XSD layers and extend it(Thanks to the XSD redefinition).

enter image description here

Issue:

infrastructureTypes.xsd:

<xs:schema xmlns:rail="http://www.railml.org/schemas/2016" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.railml.org/schemas/2016" elementFormDefault="qualified" version="2.3">
<xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>
<xs:include schemaLocation="railwayUnits.xsd"/>
<xs:include schemaLocation="railwayBaseTypes.xsd"/>
<xs:complexType name="tBasePlacedElement">
    <xs:complexContent>
        <xs:extension base="rail:tElementWithIDAndName">
            <xs:sequence>
                <xs:element name="geoCoord" type="rail:tGeoCoord" minOccurs="0" maxOccurs="1"/>
            </xs:sequence>
            <xs:attributeGroup ref="rail:aRelPosition"/>
            <xs:attributeGroup ref="rail:aAbsPosition"/>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>   

-----------------
----------------
---------------

infrastructure-GenericADM.xsd:

<xs:schema xmlns="http://www.railml.org/schemas/2016" xmlns:GenericADM="http://www.transport.alstom.com/GenericADM/1" xmlns:rail="http://www.railml.org/schemas/2016" xmlns:vc="http://www.w3.org/2007/XMLSchema-versioning" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.railml.org/schemas/2016" elementFormDefault="qualified" version="0.1" vc:minVersion="1.1">
<xs:import namespace="http://www.transport.alstom.com/GenericADM/1" schemaLocation="GenericADM.xsd"/>
<xs:redefine schemaLocation="railML.xsd">
    <xs:complexType name="tBasePlacedElement">
        <xs:complexContent>
            <xs:extension base="rail:tBasePlacedElement">
                <xs:attribute name="kPCorrectedTrolleyValue" type="rail:tLengthM" use="optional"/>
                <xs:attribute name="alternativeKP" type="rail:tLengthM" use="optional"/>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>

When i validate the XSDs infrastructure-GenericADM.xsd using Altova XMLSpy, it is giving the following error:

rail:tBasePlacedElement is already declared. Error location: xs:schema/ xs:redefine/ xs:complexType. src-expredef: <xs:complexType> 'tBasePlacedElement' does not exist in the redefined schema with target namespace 'http://www.railml.org/schema/2016'

However, the same XSDs are validated successfully using the standard tools like Oxygen XML Editor and Liquid Studio.

Can someone help to understand what is the issue.

Thank you in advance.

1
The issue, I'm afraid, is that the spec for xs:redefine is somewhat fuzzy around the edges. The authors of XSD 1.1 decided that fixing the interoperability problems was an impossible task which is why XSD 1.1 says "Note: The redefinition feature described in the remainder of this section is ·deprecated· and may be removed from future versions of this specification. Schema authors are encouraged to avoid its use in cases where interoperability or compatibility with later versions of this specification are important." - Michael Kay
Thanks for taking sometime to answer my question. These are the legacy XSDs implemented sometime back and all our internal tools are developed based on this XSD structure. When i contacted the Altova XMLSpy support team recently. They have given the following answer. "there is duplication going on in infrastructure-GenericADM.xsd. It is redefining a complex type from railML.xsd and at the same time it is importing GenericADM.xsd. Both of these schema have a chain back to infrastructureTypes.xsd. So infrastructure-GenericADM.xsd is getting tBasePlacedElement from two different places." - VinayCH
But i am not fully convinced with their answer. I feel their parser is having more restrictions. Also, how can i decide who is right between the different standard tools? - VinayCH
As suggested in my answer, I think there are cases where the spec simply doesn't give an answer, which is why XSD 1.1 deprecated the feature. - Michael Kay

1 Answers

1
votes

The issue, I'm afraid, is that the spec for xs:redefine is somewhat fuzzy around the edges. The authors of XSD 1.1 decided that fixing the interoperability problems was an impossible task which is why XSD 1.1 says

Note: The redefinition feature described in the remainder of this section is ·deprecated· and may be removed from future versions of this specification. Schema authors are encouraged to avoid its use in cases where interoperability or compatibility with later versions of this specification are important.

In particular, it really isn't well defined in the spec what should happen when module A refers to module B via two different routes, one of which has an xs:redefine step.