Menu

#704 <constraint> doesn't allow more than one child element

GREEN
closed-fixed
None
5(default)
2015-01-30
2015-01-03
rvdb
No

The content model for <constraint> is specified as:

 <rng:choice>
  <rng:text/>
  <rng:ref name="macro.anyXML"/>
 </rng:choice>

This prohibits the occurrence of more than one Schematron child element inside <constraint>. Hence, the example in the Guidelines at http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TD.html#TDTAGCONS is wrong:

<constraintSpec ident="subclauses" scheme="isoschematron">
 <constraint>
  <s:ns prefix="tei" uri="http://www.tei-c.org/ns/1.0"/>
  <s:rule context="tei:div">
   <s:assert test="not(tei:div) or count(tei:div)>1">a division must contain at
       least two subdivisions</s:assert></s:rule>
 </constraint>
</constraintSpec>

According to this limitation, all Schematron elements should instead be placed in their dedicated <constraintSpec> elements, which seems undesirable, and not in line with the prose and examples of the Guidelines.

Instead, I would propose to change the content model definition for <constraint> to:

<rng:choice>
  <rng:zeroOrMore>
    <rng:text/>
    <rng:ref name="macro.anyXML"/>
  </rng:zeroOrMore>
</rng:choice>

Discussion

  • rvdb

    rvdb - 2015-01-03
    • summary: <constraint> doesn't allow more than one child element --> <constraint> doesn't allow more than one child element
     
  • Lou Burnard

    Lou Burnard - 2015-01-04

    I assume your proposed change to the content model should have the <rng:zeroOrMore> outside the <rng:choice> rather than the other way round. This would make the content model for &constraint> identical to that for <egXML> which seems correct.

     
  • rvdb

    rvdb - 2015-01-04

    Indeed, <rng:zeroOrMore><rng:choice>...</rng:choice></rng:zeroOrMore>. Apologies, my bad.

     
  • Martin Holmes

    Martin Holmes - 2015-01-12

    Ron has done some excellent research which I believe has nailed the problem:

    The NVDL validation setup we use to validate the Guidelines source and examples allows multiple Schematron rules where tei_all doesn't. The definition of <constraint> that appears both in p5odds.odd and in p5odds-examples.odd (used for Guidelines validation) is completely different from that in constraint.xml (for regular TEI schemas). In constraint.xml we see:

    <content>
        <rng:choice>
          <rng:text/>
          <rng:ref name="macro.anyXML"/>
        </rng:choice>
      </content>
    

    while in p5odds.odd and p5odds-examples.odd, we see:

    <content>
      <zeroOrMore xmlns="http://relaxng.org/ns/structure/1.0">
        <choice>
          <text/>
          <ref name="anySchematron"/>
          <ref name="anyISOSchematron"/>
        </choice>
      </zeroOrMore>
    </content>
    

    I suspect the intention was the reverse of the result: the Guidelines content model is supposed to be more restrictive (only text or Schematron), whereas the general definition is intended to be open to XML languages other than Schematron; the problem is that the constraint as it is written allows only one instance of macro.anyXML, which itself appears to allow for only a single element. In other words, in the Guidelines we are allowed to use (and suggest as examples) complex constraints which are not actually allowed if you're working with the regular TEI schema; and we do use them (e.g. in f.xml), which means they're perfectly reasonable and should be available to everyone.

    I therefore believe this is a corrigible error, and that Ron's suggestion of this content model:

    <rng:zeroOrMore>
      <rng:choice>
        <rng:text/>
        <rng:ref name="macro.anyXML"/>
      </rng:choice>
    </rng:zeroOrMore>
    

    should be implemented as a matter of urgency, because there is at least one example in the Guidelines that can't actually be followed at the moment.

     
  • Martin Holmes

    Martin Holmes - 2015-01-29
    • assigned_to: Martin Holmes
    • Group: AMBER --> GREEN
     
  • Martin Holmes

    Martin Holmes - 2015-01-29

    After no objections and some support from Council, I've taken this ticket and will implement it.

     
  • Martin Holmes

    Martin Holmes - 2015-01-29

    Implemented at rev 13117.

     
  • Syd Bauman

    Syd Bauman - 2015-01-30
    • status: open --> closed-fixed