[tei-council] [Fwd: Re: constraint again]

Sebastian Rahtz sebastian.rahtz at oucs.ox.ac.uk
Tue Apr 21 03:33:47 EDT 2009


from Syd

-------- Original Message --------
Subject: 	Re: constraint again
Date: 	Tue, 21 Apr 2009 02:15:29 -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>
References: 	<49ECED85.9060304 at oucs.ox.ac.uk>



Sebastian -- please forward to Council.


> talking to Lou about this today raised a number of issues I need
> advice on.
>    a) if we add <desc> and friends as children of <constraint>,
>       we'd have a model of
>         gloss?,desc?,equiv?,anyXML
>      which makes both Lou and I [sic] feel uneasy. it looks too
>      much like mixed content. ie every operation has to pick out
>      "everything except gloss/desc/equiv". doable, of course, but,
>      well, icky.

I agree this is icky. (Not as bad as mixed content, but even worse
than you describe -- you have to make sure you exempt only
gloss/desc/equiv elements that are children of the <constraint>, in
case someone uses TEI <desc> elements to document some screwy schema
languages deep in the bowels of the anyXML part.)

Also would need a special-case to be expressed in DTD, no?


>      one possibility is the verbose
>         <constraint>
>           <desc>stuff</desc>
>           <content>
>              <xxxxxx/>
>           </content>
>         </constraint>
>      but that makes it confusing for people who redefine the
>      content model of <content>.
>      does this bother others?

This is better than the above (i.e., better than "{ gloss*, desc*,
equiv?, macro.anyXML }" -- you may need multiples), but it does
bother me a bit. I'd like only rng: stuff in my regular <content>,
and only sch: stuff in my <constraint>'s <content>. ODD can't express
that. 


>    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?
>      I am almost thinking I'd rather have
>        <constraintGrp ident="xyz">
>          <desc>stuff</desc>
>          <constraint scheme="schematron">
>             ... stuff ...
>          </constraint>
>          <constraint scheme="xyz">
>             .... stuff ...
>          </constraint>
>        </constraintGrp>
> 
>       repeated multiple times. the semantics would then be that
>       <constraint> children of Grp are _alternative
>       implementations_, and multiple Grps are _additive_, ie must
>       all apply.

I think this is an excellent, if verbose, solution. It also lends
itself to internationalization well:

  <constraintGrp ident="xyz">
    <gloss>X-ray Yankee Zulu</gloss>
    <gloss xml:lang="de">Xanthippe Ypsilon Zacharias</gloss>
    <gloss xml:lang="es">Xiquena Yeguna Zaragoza</gloss>
    <desc>whatever</desc>
    <desc xml:lang="de">was auch immer</desc>
    <desc xml:lang="es">lo que</desc>
    <constraint scheme="isoschematron">
      <!-- stuff ... -->
    </constraint>
    <constraint xml:lang="de" scheme="isoschematron">
      <!-- material ... -->
    </constraint>
    <constraint xml:lang="es" scheme="isoschematron">
      <!-- materia ... -->
    </constraint>
  </constraintGrp>

My only thought is that "Grp" may no longer be the appropriate affix.
Perhaps "Set" would be better? Actually, that's not the half of it --
the names are now backwards. The grouping element expresses a single
constraint. It should be called <constraint>. The elements inside
should be, uh  ... <constraintette>? No. <constrain>? Maybe. <code>?
No, has same problem as <content>. <check>? Best I've thought of, but
I bet someone else can do better.

But then, the grouping element may not be right, either, as some
folks will use Schematron to issue warnings, not errors.



-- 
Sebastian Rahtz      
Information Manager, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431



More information about the tei-council mailing list