#246 XML construct encoding within Schematron
Inside <constraintSpec> in P5 the encoding of the names of XML constructs is inconsistent. (As is the use of an initial capital and a trailing period.) I believe that this should be made consistent using the standard TEI constructs: <gi>, <att>, and <val>.
Note that doing so will not break current ODD processing,although no advantage will be gained on output (except consistency :-). This is because currently the contents of TEI element children of Schematron elements are passed along, but the tags are dropped. But in the future properly processing these constructs could be added as a feature.
As an example, I intend to check-in a new Schematron rule added to the <app> element (to enforce the “1-<lem>” rule expressed in prose in the <remarks> for <rdgGrp>) which makes use of TEI phrase-level encoding of XML construct names.
What do you mean by "inside <constraintSpec> in P5"? Are you talking about the content of the elements in the schematron namespace which <constraintSpec> contains? If so, presumably this would mean defining a prefix for the TEI namespace and then using it? This seems a bit too much like hard work... But maybe I have misunderstood your point entirely. An example would help...
Your change to app has been reverted (since it breaks the current P5 production line) pending resolution of this issue.
Yes, I'm talking about the content of the elements in the schematron namespace which <constraintSpec> contains. Yes, if you declare the Schematron namespace to be the default namespace on some element inside <constraintSpec>, then you would need to somehow explicitly state that the <gi>, <att>, or <val> element was in the TEI namespace. In most, if not all, current cases in the source of the Guidelines the Schematron elements have explicit namespace prefixes, in which case no prefix or namespace declaration is required at all. That said, I don't think the details of how the namespaces are declared should change whether or not TEI properly encodes XML constructs in the source of the Guidelines.
Do you want an example other than https://tei.svn.sourceforge.net/svnroot/tei/trunk/P5/Source/Specs/app.xml#8061?
---------
What did it break? I carefully tested the change with `make clean validate html-web exemplars` and explicitly checked the Schematron output — I found no problems.
Do I get it correctly, Syd, that you would like to have [2] instead of [1]?
[1] <sch:assert test="count( descendant::tei:lem[ generate-id( current() ) = generate-id( ancestor::tei:app[1] ) ]) < 2">Only one <lem> element may appear within a single
apparatus entry, whether it appears outside a <rdgGrp>
element or within it.</sch:assert>
[2] <sch:assert test="count( descendant::tei:lem[ generate-id( current() ) = generate-id( ancestor::tei:app[1] ) ]) < 2">Only one <gi>lem</gi> element may appear within a single
apparatus entry, whether it appears outside a <gi>rdgGrp</gi>
element or within it.</sch:assert>
And if I get that correctly, does it not require an extra catch in the XSLT for ODD to be implementable? (Granted, it wouldn't seem to be difficult or compat-breaking XSLT).
Ah, indeed. Syd's URL showed < and > to me, but the modification is more clearly visible at
http://tei.svn.sourceforge.net/viewvc/tei/trunk/P5/Source/Specs/app.xml?revision=8061&view=markup
The Council meeting 2012-09 decided not to proceed with changes here; while agreeing that the content of the assertions could well be cleaned up. It was felt that embedded TEI inside the Schematron might well just work now, but produces a hidden burden for future processors. It was not felt that there is enough advantage.