[tei-council] issues on Schematron and deprecation

[Syd Bauman]

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?

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
   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.


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"/>