[tei-council] issues on Schematron and deprecation

[Martin Holmes]

On 14-01-09 10:11 AM, Syd Bauman wrote:
> I am about ready to check-in the new extract-isosch.xsl and changes
> to the GLs to go with it.
>
> 1) Can someone remind me (a git novice) *how* to check in the
>     stylesheet change, and more importantly (other than typing fast),
>     how to check those and the GL changes in so that Mr. Jenkins uses
>     both new versions?

Can't help with Git (I can never remember the commands), but I would 
suggest committing the Stylesheet changes first; then watch Jenkins 
build the Stylesheets, and when it's two or three minutes from 
completion, check in your SF changes. The chances of this working are 
pretty small, though; when the Stylesheets build completes, it will 
trigger the P5 builds, but so will your P5 commit, and there's a good 
chance Jinks will check the P5 SVN between when you check in your P5 
changes and the Stylesheets build completes.

> 2) The changes to extract-isosch.xsl are pretty extensive. The most
>     important thing (besides adding the @validUntil stuff) is that
>     namespaces are now handled much more reasonably. However, there
>     is a possible problem; see below.
>
> 4) @validUntil is not handled when it is on a <valItem> that itself
>     is inside a <classSpec>
>
> 3) The context= of a constraint that does not have one is now
>     reasonably set when the constraint is in:
>     * elementSpec//attDef
>     * elementSpec
>     It is handled, but not very well yet, when in
>     * classSpec//attDef
>     * classSpec
>     It is not handled (but should be -- I think I know how, just
>     haven't got to it) when a child of
>     * schemaSpec

I was thinking of exactly this recently: for the Map of London project, 
we maintain a separate Schematron file full of constraints like this:

<pattern>
     <rule context="text()">
       <assert test='not(contains(., "&apos;"))'>
         "Straight apostrophe" characters are not permitted. Please use the
         Right Single Quotation Mark (U+2019) character instead.
       </assert>
     </rule>
   </pattern>

In other words, we force the use of a curly apostrophe instead of a 
straight one in all text nodes. This sort of thing should really be in 
the ODD file. Is this the sort of thing you imagine being a child of 
<schemaSpec>?

>     It is not handled (and should not be) when in
>     * macroSpec
>     I have taken the liberty of unilaterally deciding that having a
>     constraint in <macroSpec> that does not specify a context should
>     not be allowed, and added a <constraintSpec> to <constraintSpec>
>     to flag when this occurs.
>     Note that although classSpec//attDef, classSpec, and schemaSpec
>     situations are not handled well, we don't actually use these.
>
> possible problem
> -------- -------
> I'm not sure, but I think the extraction will screw up if the input
> document has two or more different URIs assigned to the same prefix.
> E.g.:
>    <constraintSpec scheme="schematron" ident="datingAttr_1.5">
>      <constraint xmlns:s="http://www.ascc.net/xml/schematron">
>        <s:pattern name="at least one dating attr">
>          <s:rule context="application|date|time">
>            <s:assert test="@when or @when-iso or @notBefore
>              or @notBefore-iso or @notAfter or @notAfter-iso or
>              @from or @from-iso or @to or @to-iso">At least one
>              date normalization attribute should be
>              specified.</s:assert>
>          </s:rule>
>        </s:pattern>
>      </constraint>
>    </constraintSpec>
>    <constraintSpec scheme="isoschematron" ident="datingAttr">
>      <constraint xmlns:s="http://purl.oclc.org/dsdl/schematron">
>        <s:pattern>
>          <s:rule context="application|date|time">
>            <s:assert test="@when or @when-iso or @notBefore
>              or @notBefore-iso or @notAfter or @notAfter-iso or
>              @from or @from-iso or @to or @to-iso">At least one
>              date normalization attribute should be
>              specified.</s:assert>
>          </s:rule>
>        </s:pattern>
>      </constraint>
>    </constraintSpec>
> Here the prefix 's' has been bound to 2 different URIs. We don't have
> this situation in P5,[1] so I don't think we should let it stop us
> from moving on. But if a user has this situation in her customization
> ODD, and then tries to reference thee 's:' prefix in a <constraint>
> (either explicitly, or because the <constraint> is in a specification
> with an ns= value that's one of the two URIs assigned to 's') ... I
> don't know what will happen, but I doubt it will be the right thing.

This would be a perverse case, surely. Even if it's not technically 
wrong, it would be bad practice to bind the same prefix to two different 
namespaces in the same document.

Cheers,
Martin

> Notes
> -----
> [1] In case you're curious, the namespaces prefix bindings we have in P5 are:
>       79295   <ns prefix="xml"   uri="http://www.w3.org/XML/1998/namespace"/>
>       79295   <ns prefix="rng"   uri="http://relaxng.org/ns/structure/1.0"/>
>        4630   <ns prefix="sch"   uri="http://purl.oclc.org/dsdl/schematron"/>
>        4078   <ns prefix="s"     uri="http://www.ascc.net/xml/schematron"/>
>         115   <ns prefix="teix"  uri="http://www.tei-c.org/ns/Examples"/>
>          37   <ns prefix="dcr"   uri="http://www.isocat.org/ns/dcr"/>
>          29   <ns prefix="my"    uri="http://www.example.org/ns/nonTEI"/>
>          21   <ns prefix="ext"   uri="http://www.example.org/ns/nonTEI"/>
>          13   <ns prefix="n"     uri="http://www.example.org/ns/nonTEI"/>
>          12   <ns prefix="hr"    uri="http://www.example.org/ns/nonTEI"/>
>          10   <ns prefix="svg"   uri="http://www.w3.org/2000/svg"/>
>           9   <ns prefix="gml"   uri="http://www.opengis.net/gml"/>
>           9   <ns prefix="a"     uri="http://relaxng.org/ns/compatibility/annotations/1.0"/>
>           8   <ns prefix="gram"  uri="http://www.gram.org"/>
>           4   <ns prefix="xlink" uri="http://www.w3.org/1999/xlink"/>
>
>