[tei-council] issues on Schematron and deprecation

[Hugh Cayless]

On Jan 9, 2014, at 13:11 , Syd Bauman <s.bauman at neu.edu> 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?
> 


git add extract-isosch.xsl
git commit -m "Your commit message."
git pull —rebase origin master 		#make sure your commit gets written on top of any remote commits
git push origin master				#commit in the svn sense

Should do it. This assumes the usual GitHub setup, where your remote is nicknamed "origin" and your main branch is named "master".

> 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"/>
> 
> -- 
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> 
> PLEASE NOTE: postings to this list are publicly archived