[tei-council] the new <constraint> element

[James Cummings]

Sebastian Rahtz wrote:
> Syd Bauman wrote:
>> * Why limit values of scheme= so severely? While I don't actually
>>   know anyone who uses DSD, I don't see any reason to exclude it.
>>   Would be nice if someone could develop a list of all the languages
>>   that would make sense to use inside <constraint>.
>>   
> My thinking was that to limit it at the start, and
> add more languages as requested. You can use
> "private" for anything, after all, and you'll have to
> implement it....

This seems reasonable to me.

>> * Why is it "constraintList" rather than "listConstraint", which
>>   would be analogous to <listPerson>, <listBibl>, etc.?

I agree with others that constraintGrp is better than listConstraint. 
Should we be considering replacing attList (with attGrp?) at some 
undefined point in the future?

>>   But I think it might be a lot more logical to use:
>>     <constraintList>
>>       <constraint scheme="schematron"> schematron 1.6 for A </constraint>
>>       <constraint scheme="isoschematron"> ISO schematron for A </constraint>
>>       <constraint scheme="private"> CLIX for A </constraint>
>>     </constraintList>
>>     <constraintList scheme="isoschematron">
>>       <constraint scheme="schematron"> schematron 1.6 for B </constraint>
>>       <constraint scheme="isoschematron"> ISO schematron for B </constraint>
>>       <constraint scheme="private"> CLIX for B </constraint>
>>     </constraintList>
>>   
> Yes, I can see the strength of this argument. I could
> argue either way. What do the rest of the Council think.

I'm not sure I understand why this is better?  I assume the second 
constraintList (or Grp) shouldn't have a @scheme attribute?  I remember 
that in the meeting we discussed whether constraints should be grouped 
arbitrarily or by inherited scheme.  I guess my preference would be to 
allow for typical TEI flexibility in doing both.  I might want to group 
some constraints together for one reason even though they have different 
schemes, and in other places put all the xsl ones together.  i.e. I 
might want to have in one single ODD:

     <constraintGrp xml:id="myFunnyGrouping">
         <constraint scheme="schematron"/>
         <constraint scheme="isoschematron"/>
         <constraint scheme="xsl"/>
         <constraint scheme="private"/>
      </constraintGrp>

     <constraintGrp xml:id="myXSLGrouping" scheme="xsl">
         <constraint />
         <constraint />
      </constraintGrp>

     <constraintGrp xml:id="myCLIXGrouping" scheme="private">
         <constraint />
         <constraint />
      </constraintGrp>

That is, for whatever reason, I want to group some constraints together 
giving them each a @scheme, and in other places I want them all to 
inherit a @scheme rather than repeat it.

Best,
-James

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