[tei-council] constraint again

[Lou Burnard]

Sebastian Rahtz wrote:

> 
>    b) is <constraintGrp> a necessary container, or a convenience
>      semantic or syntactic grouping? ie
>        - can it be omitted, and does <constraint> therefore have
>          @scheme
>        - does the Grp need its own ident and description?

Whether or not <constraintGrp> is needed, I think <constraint> must have 
@scheme. As my previous post indicates, I think they both might also 
have @type, or (better) @function (@scope?) as well, to say something 
about the kind of constraint being documented.

As Sebastian says, we're not clear whether the purpose of 
<constraintGrp> is primarily

(a) to provide a default value for these attributes applicable to all 
its child <constraint> elements

(b) just (like <attList>) to wrap around all the <constraint>s within 
the parent *Spec

The two are not mutually exclusive of course, but the former implies 
that it's optional.

 > the semantics would then be that
>       <constraint> children of Grp are _alternative implementations_,
>       and multiple Grps are _additive_, ie must all apply.
> 

Does a validating TEI application have to ensure that *all* constraints 
are observed, or only those which are expressed in a scheme it knows how 
to handle? Presumably the latter. Considering those constraints which it 
cannot handle, the existence of "alternatives" suggests that some of 
these unhandle-able ones  matter more than others: if you can't handle 
constraint X1 in scheme 1, but you can handle  constraint X2 in scheme 
2, and X1 and X2 are labelled as "alternates"  then you're obviously 
nearer enlightenment than if you can't be doing with anything in scheme 
1 and no X2 exists. On the face of it, this sounds cool. As Sebastian 
suggests, you could indicate that X1 and X2 are actually alternate 
versions of each other by wrapping them in a constraintGroup and 
specifying a (single) @ident X on that.

On balance however I think (and yesterday he persuaded me) this may be 
over-egging the pudding: certainly, it complicates implementation quite 
a lot. The differences between schemes are not purely syntactic: they 
also differ greatly in expressivity. So while X2 might be re-expressible 
in the language of X1, the chances that it will always be exactly the 
*same* constraint seem slim to me.  It also seems a lot more realistic 
to say that TEI validation implies that *as many as possible* of the 
specified constraints are satisfied. This allows an implementation to 
decide (and be upfront about about) those which it cannot do; leaving 
the door open for the really obsessive TEI-conformant validator which 
validates against all possible schemes. (and probably always washes 
behind its ears, tidies its room before sleeping, and generally needs to 
get out more)