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

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

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:

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> Constraint rules in the Schematron 1.* language must be inside a ﹤constraintSpec﹥ with a value of 'schematron' on the @scheme attribute </constraint> </constraintSpec>

<constraintSpec scheme="isoschematron" ident="old-schematron-uses-old-schematron"> <constraint> Constraint rules in the ISO Schematron language must be inside a ﹤constraintSpec﹥ with a value of 'isoschematron' on the @scheme attribute </constraint> </constraintSpec>

<constraintSpec scheme="isoschematron" ident="xsl-constraint-uses-xslt"> <constraint> Constraint rules in the XSLT language must be inside a ﹤constraintSpec﹥ with a value of 'xsl' on the @scheme attribute </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 http://purl.oclc.org/dsdl/schematron'"/> 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. But I'm hoping there is a less cumbersome way to express that.

...

The proposed change seems reasonable to me as well.