Please take a look at this bug
Hi all, Could I ask Council to take a look at this bug? <http://sourceforge.net/p/tei/bugs/704/> I believe the explanation in the final comment is correct, that it's a corrigible error, and that it's fairly egregious (we give an example in the Guidelines of something that isn't actually permitted in standard TEI schemas; we get round this ourselves in the actual Guidelines source by customizing our ODD schemas). I'd like the OK to fix this; I think it should be release-blocking, and it's holding up the work Ron is doing to integrate the JTEI schema into our system. If there are no objections in the next week, I'll assume assent and implement the fix suggested on the ticket. Cheers, Martin
Hi Martin, I am used to writing one rule per constraint and one constraint per constraintSpec -- possibly this is a result of the limitations caused by this bug. If we switch to the proposed model, it would allow multiple rules per constraint. Would that break anything? My feeling is that it wouldn't, but what do others think? Raff On Thu, Jan 22, 2015 at 11:08 AM, Martin Holmes <mholmes@uvic.ca> wrote:
Hi all,
Could I ask Council to take a look at this bug?
<http://sourceforge.net/p/tei/bugs/704/>
I believe the explanation in the final comment is correct, that it's a corrigible error, and that it's fairly egregious (we give an example in the Guidelines of something that isn't actually permitted in standard TEI schemas; we get round this ourselves in the actual Guidelines source by customizing our ODD schemas). I'd like the OK to fix this; I think it should be release-blocking, and it's holding up the work Ron is doing to integrate the JTEI schema into our system.
If there are no objections in the next week, I'll assume assent and implement the fix suggested on the ticket.
Cheers, Martin -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
Hi Raff, On 15-01-22 08:56 AM, Raffaele Viglianti wrote:
Hi Martin,
I am used to writing one rule per constraint and one constraint per constraintSpec -- possibly this is a result of the limitations caused by this bug. If we switch to the proposed model, it would allow multiple rules per constraint. Would that break anything? My feeling is that it wouldn't, but what do others think?
It shouldn't break anything, because we use it in the Guidelines itself: <http://sourceforge.net/p/tei/code/HEAD/tree/trunk/P5/Source/Specs/f.xml> We've given ourselves permission to do it, but denied it to everyone else. :-) Cheers, Martin
Raff
On Thu, Jan 22, 2015 at 11:08 AM, Martin Holmes <mholmes@uvic.ca> wrote:
Hi all,
Could I ask Council to take a look at this bug?
<http://sourceforge.net/p/tei/bugs/704/>
I believe the explanation in the final comment is correct, that it's a corrigible error, and that it's fairly egregious (we give an example in the Guidelines of something that isn't actually permitted in standard TEI schemas; we get round this ourselves in the actual Guidelines source by customizing our ODD schemas). I'd like the OK to fix this; I think it should be release-blocking, and it's holding up the work Ron is doing to integrate the JTEI schema into our system.
If there are no objections in the next week, I'll assume assent and implement the fix suggested on the ticket.
Cheers, Martin -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
I'm in favour of the proposed change: it seems entirely reasonable that a single <constraint> might need to be expressed as more than one <sch:rule>. What I have never really understood is why we don't allow multiple <constraint>s within a single <constraintSpec>. But that is not the point at issue here. On 22/01/15 17:01, Martin Holmes wrote:
Hi Raff,
On 15-01-22 08:56 AM, Raffaele Viglianti wrote:
Hi Martin,
I am used to writing one rule per constraint and one constraint per constraintSpec -- possibly this is a result of the limitations caused by this bug. If we switch to the proposed model, it would allow multiple rules per constraint. Would that break anything? My feeling is that it wouldn't, but what do others think?
It shouldn't break anything, because we use it in the Guidelines itself:
<http://sourceforge.net/p/tei/code/HEAD/tree/trunk/P5/Source/Specs/f.xml>
We've given ourselves permission to do it, but denied it to everyone else. :-)
Cheers, Martin
Raff
On Thu, Jan 22, 2015 at 11:08 AM, Martin Holmes <mholmes@uvic.ca> wrote:
Hi all,
Could I ask Council to take a look at this bug?
<http://sourceforge.net/p/tei/bugs/704/>
I believe the explanation in the final comment is correct, that it's a corrigible error, and that it's fairly egregious (we give an example in the Guidelines of something that isn't actually permitted in standard TEI schemas; we get round this ourselves in the actual Guidelines source by customizing our ODD schemas). I'd like the OK to fix this; I think it should be release-blocking, and it's holding up the work Ron is doing to integrate the JTEI schema into our system.
If there are no objections in the next week, I'll assume assent and implement the fix suggested on the ticket.
Cheers, Martin -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
The proposed change seems reasonable to me as well. f 2015-01-22 22:48 GMT+01:00 Lou Burnard <lou.burnard@retired.ox.ac.uk>:
I'm in favour of the proposed change: it seems entirely reasonable that a single <constraint> might need to be expressed as more than one <sch:rule>.
What I have never really understood is why we don't allow multiple <constraint>s within a single <constraintSpec>. But that is not the point at issue here.
On 22/01/15 17:01, Martin Holmes wrote:
Hi Raff,
On 15-01-22 08:56 AM, Raffaele Viglianti wrote:
Hi Martin,
I am used to writing one rule per constraint and one constraint per constraintSpec -- possibly this is a result of the limitations caused by this bug. If we switch to the proposed model, it would allow multiple rules per constraint. Would that break anything? My feeling is that it wouldn't, but what do others think?
It shouldn't break anything, because we use it in the Guidelines itself:
<http://sourceforge.net/p/tei/code/HEAD/tree/trunk/P5/Source/Specs/f.xml>
We've given ourselves permission to do it, but denied it to everyone else. :-)
Cheers, Martin
Raff
On Thu, Jan 22, 2015 at 11:08 AM, Martin Holmes <mholmes@uvic.ca> wrote:
Hi all,
Could I ask Council to take a look at this bug?
<http://sourceforge.net/p/tei/bugs/704/>
I believe the explanation in the final comment is correct, that it's a corrigible error, and that it's fairly egregious (we give an example in the Guidelines of something that isn't actually permitted in standard TEI schemas; we get round this ourselves in the actual Guidelines source by customizing our ODD schemas). I'd like the OK to fix this; I think it should be release-blocking, and it's holding up the work Ron is doing to integrate the JTEI schema into our system.
If there are no objections in the next week, I'll assume assent and implement the fix suggested on the ticket.
Cheers, Martin -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
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> <sch:report test="tei:constraint/s:* and not(@scheme='schematron')">Constraint rules in the Schematron 1.* language must be inside a ﹤constraintSpec﹥ with a value of 'schematron' on the @scheme attribute </sch:report> </constraint> </constraintSpec> <constraintSpec scheme="isoschematron" ident="old-schematron-uses-old-schematron"> <constraint> <sch:report test="tei:constraint/sch:* and not(@scheme='isoschematron')">Constraint rules in the ISO Schematron language must be inside a ﹤constraintSpec﹥ with a value of 'isoschematron' on the @scheme attribute </sch:report> </constraint> </constraintSpec> <constraintSpec scheme="isoschematron" ident="xsl-constraint-uses-xslt"> <constraint> <sch:report test="tei:constraint/xsl:* and not(@scheme='xsl')">Constraint rules in the XSLT language must be inside a ﹤constraintSpec﹥ with a value of 'xsl' on the @scheme attribute </sch:report> </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 <sch:rule context="tei:constraintSpec[@scheme='isoschematron']"> <sch:let name="ns2t" value="'http://purl.oclc.org/dsdl/schematron'"/> <sch:assert test="( for $e in (child::tei:content/child::*) return if (namespace-uri($e) eq $ns2t ) then true() else false()) = false()">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.</sch:assert> </sch:rule> But I'm hoping there is a less cumbersome way to express that.
The proposed change seems reasonable to me as well.
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: <elementSpec ident="content" ... be this: <elementSpec ident="constraint" Cheers, Martin On 15-01-29 11:24 AM, Syd Bauman wrote:
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> <sch:report test="tei:constraint/s:* and not(@scheme='schematron')">Constraint rules in the Schematron 1.* language must be inside a ﹤constraintSpec﹥ with a value of 'schematron' on the @scheme attribute </sch:report> </constraint> </constraintSpec>
<constraintSpec scheme="isoschematron" ident="old-schematron-uses-old-schematron"> <constraint> <sch:report test="tei:constraint/sch:* and not(@scheme='isoschematron')">Constraint rules in the ISO Schematron language must be inside a ﹤constraintSpec﹥ with a value of 'isoschematron' on the @scheme attribute </sch:report> </constraint> </constraintSpec>
<constraintSpec scheme="isoschematron" ident="xsl-constraint-uses-xslt"> <constraint> <sch:report test="tei:constraint/xsl:* and not(@scheme='xsl')">Constraint rules in the XSLT language must be inside a ﹤constraintSpec﹥ with a value of 'xsl' on the @scheme attribute </sch:report> </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 <sch:rule context="tei:constraintSpec[@scheme='isoschematron']"> <sch:let name="ns2t" value="'http://purl.oclc.org/dsdl/schematron'"/> <sch:assert test="( for $e in (child::tei:content/child::*) return if (namespace-uri($e) eq $ns2t ) then true() else false()) = false()">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.</sch:assert> </sch:rule> But I'm hoping there is a less cumbersome way to express that.
The proposed change seems reasonable to me as well.
Well, well. Turns out the constraints I was suggesting are already there. :-) Although I think my 2nd suggestion in my e-mail is somewhat better, and will deal with that via a ticket soon. Not only can not think of why an empty <constraint> is helpful, it seems silly and possibly puts a bit of a burdon on processing. And you're absolutly right about my erroneous value of ident=, of course.
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:
<elementSpec ident="content" ...
be this:
<elementSpec ident="constraint"
participants (5)
-
Fabio Ciotti -
Lou Burnard -
Martin Holmes -
Raffaele Viglianti -
Syd Bauman