[tei-council] [Fwd: more on constraint]

[James Cummings]

 From Syd.

-------- Original Message --------
Subject: more on constraint
Date: Tue, 21 Apr 2009 10:25:31 -0400
From: Syd Bauman <Syd_Bauman at Brown.edu>
Reply-To: Syd_Bauman at Brown.edu
To: Sebastian Rahtz <sebastian.rahtz at oucs.ox.ac.uk>
CC: James Cummings <james.cummings at oucs.ox.ac.uk>

[This is CCed to James as it looks like SR didn't forward my previous
one on to Council!]

I have scanned the thread so far, and thank Lou for reminding us
about the relationship between the proposed <constraint> and the
existing <content>. I think he is absolutely right, they are similar
enough that they have to be considered simultaneously, and painted
with the same brush, as it were.

However, I think I'd prefer the reverse logic: it's not that we
should have a <content> in our constraint thingy. It's that what we
call <content> should really be <constraint scheme="relaxng">.

[And I'll also note that the observation that both Sebastian and I
have made -- that one wants only RELAX NG content in a <content> or
<constraint scheme="relaxng">, and only Schematron content in a
<constraint scheme="isoschematron"> -- is true, but we don't need
different element names so we can enforce that with ODD -> RNG
content models, we can enforce it with ODD -> Schematron constraints!
:-]

<elementSpec>
   <desc/>
   <constraintGrp>
     <constraint scheme="relaxng">
       <!-- what we would now put in <content> goes here -->
     </constraint>
   </constraintGrp>
   <constraintGrp>
     <desc/>
     <constraint scheme="schematron16">
       <!-- some Schematron 1.6 code, messages in English -->
     </constraint>
     <constraint scheme="isoschematron" xml:lang="fr">
       <!-- some ISO Schematron code, messages in French -->
     </constraint>
   </constraintGrp>
</elementSpec>

Semantics as Sebastian mentioned before:

* A <constraintGrp> contains multiple alternative ways of expressing
   a single constraint. The expected behavior of a processor is to
   choose the <constraint> that makes the most sense given the
   circumstances (available validation engines, preferred natural
   language), and use that.

* Multiple <constraintGrp>s are allowed; they express different
   constraints.

More thoughts:

* Content model of <constraintGrp> could be
     ( model.glossLike*, constraint+ )
   or variant thereof.

* Content model of <constraint> could be macro.anyXML.

* In some circumstances (like <elementSpec>) at least one <constraint
   scheme="relaxng"> (and thus a parent <constraintGrp>) is required.

* EITHER the number of <constraint>s in a given closed scheme (i.e.,
   RELAX NG) has to be no more than 1, OR we need to give the
   processor a way to choose which to use. More on that some other
   time if people are interested. My gut instinct is to limit closed
   schemas to 1 and only 1 <constraint> at first, and see if there is
   demand for multiples.

* The above can be constrained by a <constraint>. :-)

* It might be better to call <constraint> and <constraintGrp>
   something else, but I'm not sure what.


-- 
Dr James Cummings, Research Technologies Service, University of Oxford
James dot Cummings at oucs dot ox dot ac dot uk