[XSD] Alternatieve definitie van een element?

[MrBucket]

Stel, ik zit met het volgende stukje xml:

XML:

<MyElement>
  <Title match-mode="Tolerant" tolerance="10">Acme</Title>
  <!-- ... -->
</MyElement>

Nu wil ik dit fragment tegen een xsd kunnen valideren. Voor match-mode geldt dat het de waarde "Strict", "Regex" of "Tolerant" mag hebben (dit is op te lossen met een simpele enumeration constraint)
maar daarnaast wil ik dat:
* het tolerance-attribuut verplicht is als match-mode="Tolerant"
* het tolerance-attribuut anders verboden is.

Ik dacht dit op te lossen met twee definities voor het Title element, 1 voor de Tolerant variant en 1 voor de andere 2:

XML:

  <xs:complexType name="TitleEltTolerant">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="match-mode" form="unqualified" type="MatchModeType" fixed="Tolerant" />
        <xs:attribute name="tolerance" form="unqualified" type="xs:string" use="required"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  
  <xs:complexType name="TitleElt">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="match-mode" form="unqualified">
          <xs:simpleType>
            <xs:restriction base="MatchModeType">
              <xs:enumeration value="Strict" />
              <xs:enumeration value="Regex" />
            </xs:restriction>
          </xs:simpleType>
        </xs:attribute>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

Dit gedeelte werkt nog, maar als ik vervolgens definieer dat het Title-element een van beide definities mag hebben:

XML:

  <xs:element name="Watch" minOccurs="0" maxOccurs="unbounded">
    <xs:complexType>
      <xs:sequence>
        <xs:choice>
          <xs:element name="Title" type="TitleElt" minOccurs="1" maxOccurs="1" />
          <xs:element name="Title" type="TitleEltTolerant" minOccurs="1" maxOccurs="1" />
        </xs:choice>
        <!-- ....-->
      </xs:sequence>
    </xs:complexType>
  <xs:element>

Dan krijg ik de foutmelding "Multiple definition of element 'Title' causes the content model to become ambiguous. A content model must be formed such that during validation of an element information item sequence, the particle contained directly, indirectly or implicitly therein with which to attempt to validate each item in the sequence in turn can be uniquely determined without examining the content or attributes of that item, and without any information about the items in the remainder of the sequence."
Blijkbaar wil de xsd validator niet eerst in het element hoeven kijken om te bepalen om welke variant het gaat.

Is er nog een andere manier om hetgeen wat ik wil te realiseren, of is dit gewoon een beperking van xsd?

[MrBucket]

*Kickje*
Niemand?

[Amras]

Volgens mij worden zulke regels - veld X verwacht als veld Y = 'Foo' - niet ondersteund door XSD. Je zou kunnen kijken naar Schematron, dat biedt mogelijkheden om dit soort regels toe te voegen aan je schema definitie; dit gaat je echter alleen helpen als je een implementatie van Schematron kunt vinden voor jouw platform, helaas.

[kluyze]

Kan je niet beter de tolerance zeroOrMore maken en indien de tolerance niet gegeven is, heeft deze de waarde 0? Dus een default value van 0. Ik denk niet dat er een manier is om dit te doen, al is het wel al even geleden dat ik nog met schema's (en dan voornamelijk RNG) gewerkt heb.

[ Voor 5% gewijzigd door kluyze op 02-08-2010 20:18 ]

[MrBucket]

Amras schreef op maandag 02 augustus 2010 @ 20:00:
Volgens mij worden zulke regels - veld X verwacht als veld Y = 'Foo' - niet ondersteund door XSD.

Hmm, daar was ik eigenlijk al een beetje bang voor...

Je zou kunnen kijken naar Schematron, dat biedt mogelijkheden om dit soort regels toe te voegen aan je schema definitie; dit gaat je echter alleen helpen als je een implementatie van Schematron kunt vinden voor jouw platform, helaas.

Van wat ik van wikipedia kan afleiden (de site zelf lijkt niet bereikbaar?) lijkt me dit behoorlijk zwaar geschut. Wel praktisch natuurlijk als je veel exotische controles moet doen, maar wellicht een beetje overkill voor mijn situatie

kluyze schreef op maandag 02 augustus 2010 @ 20:18:
Kan je niet beter de tolerance zeroOrMore maken en indien de tolerance niet gegeven is, heeft deze de waarde 0? Dus een default value van 0. Ik denk niet dat er een manier is om dit te doen, al is het wel al even geleden dat ik nog met schema's (en dan voornamelijk RNG) gewerkt heb.

Zoiets doe ik nu ook... tolerance is nu gewoon optional. In code controleer ik of match-mode = Tolerant, en afhankelijk daarvan dwing ik af dat tolerance verplicht is of juist niet mag bestaan.

Het was mooi geweest als ik dit niet in code had hoeven doen, maar dat is meer vanuit puristisch oogpunt dan dat er geen manier om heen te vinden is...

Bedankt voor het meedenken in ieder geval