0

Since several years, I have used this architecture in my models.

I have 3 models:

  • object which is the main model,
  • A and B which extend the object model and add new elements.

object.xsd:

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">

  <xs:include schemaLocation="A.xsd"/>
  <xs:include schemaLocation="B.xsd"/>

  <xs:complexType name="object">
    <xs:sequence>
      <xs:element name="elt1" type="xs:token"/>
    </xs:sequence>
  </xs:complexType>

  <xs:element name="object" type="object"/>

</xs:schema>

A.xsd:

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">

  <xs:include schemaLocation="object.xsd"/>

  <xs:complexType name="A">
    <xs:complexContent>
      <xs:extension base="object">
        <xs:sequence>
          <xs:element name="elt2" type="xs:token"/>
          <xs:element name="elt3" type="xs:token"/>
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

</xs:schema>

B.xsd:

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">

  <xs:include schemaLocation="object.xsd"/>

  <xs:complexType name="B">
    <xs:complexContent>
      <xs:extension base="object">
        <xs:sequence>
          <xs:element name="elt4" type="xs:token"/>
          <xs:element name="elt5" type="xs:token"/>
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

</xs:schema>

I use the xsi:type in the example to choose if the object is of type A or B. Here is the example associated to A:

<?xml version="1.0" encoding="UTF-8"?>

<object xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="A">
  <elt1>test1</elt1>
  <elt2>test2</elt2>
  <elt3>test3</elt3>
</object>

Some of my partnairs import the XSD schemas in their ERP to create their class objects. However they have to adapt the files I provide to import them correctly and to be able to exploit them.

I wonder if I use the xsi:type correctly. Indeed, there is no reference to the xsi namespace (xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance") in the XSD. It is the same with the xsi:type reference, how their ERP can know to add it?

lovelace63
  • 352
  • 1
  • 6
  • 15
  • You have the mechanics right. See duplicate link for further details. At a design aesthetic level, however, to require use of `xsi:type` in this manner undermines the completeness of your XSD in expressing constraints that you wish your document to meet. (Your partners have reason to be dissatisfied.) Better to avoid generic element names such as `object` so that you can constrain content models based upon element names better in the XSD directly. – kjhughes Apr 10 '18 at 13:28

1 Answers1

1

Yes you are using xsi:type correctly. (It's not a design I greatly like, but that's irrelevant.)

You don't need to declare the xsi namespace (or prefix) in your schema, only in your instance document.

One reason I don't greatly like this design is that users of this schema have to understand it in order to create instance documents, that is, they need to understand that the instance document needs to contain an xsi:type attribute (and therefore to bind the "xsi" prefix).

Michael Kay
  • 156,231
  • 11
  • 92
  • 164
  • Thank you Michael for your quick answer. If I use correctly the xsi:type, how can help my partners to consume the xsd I provide? You say that you don't greatly like this solution, what solution do you use? – lovelace63 Apr 10 '18 at 12:11
  • (A) If you design a schema then it's your responsibility to write documentation to tell people how to use it. I can't help you with that. (B) In preference to xsi:type I would use XSD 1.1 conditional type assignment, which allows you to use your own attribute in place of xsi:type to distinguish different message types. – Michael Kay Apr 10 '18 at 16:09
  • CTA on xsd1.1 is not possible because this standard is not implemented in our partners' tools. The documentation exists but is not sufficent. They don't understand how to specify the xsi:type in THEIR software. The best I can do is to modify my schema and do not use the xsi... but I am blocked with element declaration consistency. – lovelace63 Apr 11 '18 at 12:33
  • This has strayed beyond the bounds of a technical programming question to a matter of architecture and strategy in the face of non-technical constraints. – Michael Kay Apr 11 '18 at 16:34