Re: [tei-council] Please take a look at this bug

Hi Syd, Our concern was to fix a bug that was impeding our implementation of the JTEI schema, and actually made our own examples invalid. If you'd like to extend the ticket to add the new constraints, please go ahead. As far as <oneOrMore> vs <zeroOrMore> is concerned, as you say, I don't think it makes any difference; as long as we can put multiple things in the Schematron namespace in there, I'm happy. Perhaps someone can think of a reason why an empty <constraint> would be useful? In your code below, shouldn't this:

Sorry I didn't weigh in earlier. I was busy prepping for my TEI Customization workshop (thanks for the help, guys), then got hit with a blizzard.

And I see that Martin checked in the change only a few hours ago! Sigh.

I have two thoughts:

1) Shouldn't it be <oneOrMore> instead of <zeroOrMore>? Yes, the effect is the same (since a text node may be the empty string), but I think it's a wee bit clearer.

2) While we're fixing this declaration, shouldn't we a) check for proper (see next para) use of various constraint languages? b) use Pure ODD?

Hard to say what exactly is proper. My first (I think incorrect) instinct is something like the following (which is expressed as a customization ODD so I had somewhere to hang the namespaces, which you'll need to understand it).

--------- start --------- <elementSpec ident="content" mode="change" module="tagdocs" xmlns="http://www.tei-c.org/ns/1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:sch="http://purl.oclc.org/dsdl/schematron" xmlns:s="http://www.ascc.net/xml/schematron" >

<content> <alternate minOccurs="1" maxOccurs="unbounded"> <textNode/> <macroRef key="macro.anyXML"/> </alternate> </content>

<constraintSpec scheme="isoschematron" ident="iso-schematron-uses-iso-schematron"> <constraint> Constraint rules in the Schematron 1.* language must be inside a ﹤constraintSpec﹥ with a value of 'schematron' on the @scheme attribute </constraint> </constraintSpec>

<constraintSpec scheme="isoschematron" ident="old-schematron-uses-old-schematron"> <constraint> Constraint rules in the ISO Schematron language must be inside a ﹤constraintSpec﹥ with a value of 'isoschematron' on the @scheme attribute </constraint> </constraintSpec>

<constraintSpec scheme="isoschematron" ident="xsl-constraint-uses-xslt"> <constraint> Constraint rules in the XSLT language must be inside a ﹤constraintSpec﹥ with a value of 'xsl' on the @scheme attribute </constraint> </constraintSpec> </elementSpec> --------- end ---------

But these are not quite the right constraints, though. Because if scheme=isoschematron, e.g., elements from the XSL namespace (e.g., xsl:key) may be valid. So we should only be checking the NS of the children of <constraint>, I guess.

I.e., something like http://purl.oclc.org/dsdl/schematron'"/> Constraint rule children of ﹤constraint﹥ that is itself a child of a ﹤constraintSpec﹥ with a @scheme attribute of 'isoschematron' must be in the ISO Schematron namespace. But I'm hoping there is a less cumbersome way to express that.

...

The proposed change seems reasonable to me as well.