CODEWITHSUNDEEP
xmlxsd
Martin
Martin

Reputation: 2096

Get rid of xs:type attribute

Consider the following xml:

<Awesome xs:type="AB">
  <a />
  <b />
</Awesome>
<Awesome xs:type="CD">
  <f />
  <c />
  <e />
  <d />
</Awesome>

This can be specified with this schema:

<xs:complexType name="base" abstract="true" />
<xs:complexType name="AB">
  <xs:complexContent>
    <xs:extension base="base">
      <xs:all>
        <xs:element name="a" />
        <xs:element name="b" />
      </xs:all>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>
<xs:complexType name="CD">
  <xs:complexContent>
    <xs:extension base="base">
      <xs:all>
        <xs:element name="c" />
        <xs:element name="d" />
        <xs:element name="e" />
        <xs:element name="f" />
      </xs:all>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>

Considering the potential users of the schema, I’d like to keep the xml as simple as possible (and that’s why I used all and not sequence) and prefer to get rid of the xs:type attributes.

Can this be specified in a schema? Maybe with a different approach?

Upvotes: 0

Views: 86

Answers (1)

C. M. Sperberg-McQueen
C. M. Sperberg-McQueen

Reputation: 25054

The simplest thing for writing XSD (and the simplest thing for users, it says here) is to follow the principle that if one Awesome element is required to contain an a and a b, and another is required to contain some sequence of c, d, e, and f, then they are not the same kind of thing and should have different names.

If you call them Awesome-ab and Awesome-cdef, the schema is trivial and it's easy for users to understand when they are allowed to use a and b as children and when they use the other elements.

The xsi:type mechanism was added precisely for cases where the vocabulary designer wants to call different things by the same name but still validate them against different types.

If you don't want to use different names for the elements of different type, and you don't want to use xsi:type to signal the difference in type, how do you propose that the validator should know which type to use? Clairvoyance would be a good approach, but I understand it's hard to implement.

Upvotes: 1

Related Questions