[tei-council] TEI Conformance

[Sebastian Rahtz]

Syd Bauman wrote:
> Am I mis-remembering -- I thought you (Sebastian) were the one who
> convinced Council that user-added elements "had" to be in the TEI
> namespace! (When was that -- 2002?) I still regret not feeling I knew
> enough about how namespaces worked at the time to object.
>   
whichever way, that discussion has not
yet bound us, since we are only now addressing
the relevant part of the Guidelines. So either or both
of is still luckily have time to change our minds
> is a lot nicer than
>
>       <div type="letter">
>         <dateline>Written in an office that's so cold I can almost
>         see my breath</dateline>
>         <salute>Dear James</salute>
>         <p>Namespaces: can't live with 'em, can't ignore 'em.</p>
>         <signed>Syd</signed>
>         <syd:ps>If I weren't so cold I would have thought of
>         something funny</syd:ps>
>       </div>
>   
depends whether <ps> can be <equiv>ed or not, doesn't it?
>  I am very
> worried that if we were to say something simple like "add any
> elements you want, just use an ODD and put 'em in a different
> namespace" we would leave the door open for funding agencies to say
> "if you want funding your document has to be TEI without use of other
> namespaces" or some such. 
that would be good :-}
> If we do this, we have to define
> conformance *very* carefully and *very* explicitly to ensure that
> Modifications and Extensions are still encouraged.
>   
isn't that exactly where we are, doing that careful
and explicit wording?
> * Does <equiv> relate only to syntax, or to semantics also?
>   
eh? not sure I get what you have in mind here?
I thought it was only semantics?
> * I know of at least 2 schemas in the world that use an invented
>   element <called> to deliberately conflate the TEI <mentioned> and
>   <soCalled> elements. How does an <equiv> say that element X could
>   map to either Y or Z?
>   
interesting. since its ambiguous, it falls outside <equiv>,
I'd say. I think James' prose is implying that <equiv>-ing
is reversible.
> * If, in my schema, <X type="a"> maps to a TEI <Y> element, and <X
>   type="b"> maps to a TEI <Z> element ...
>   
that's just a matter of how we express things in <equiv>.
Using the XSLT notation I proposed, it would not be an issue.
> * How similar does the syntax (and semantics?) of my invented element
>   have to be to the TEI vanilla element to call it equivalent? E.g.,
>   for taking meeting minutes I have invented an <action> element.
>   (This is true, BTW.) It is roughly equivalent to a TEI <note>
>   element -- semantically similar[1], would belong to class
>   model.noteLike if it were in P5, etc. But it has a very restrictive
>   content model that allows no PCDATA and only 3 children: <name>,
>   <resp>, and <date>. Should it be listed as <equiv> to a <note>?[2]
...
> [2] I'm inclined to say "no", because I think <syd:A> being
>     equivalent to <tei:B> means that if you (piece of software) know
>     how to process a <tei:B>, then you will be able to process a
>     <syd:A> (even if not optimally). This is not true in the case
>     above, because <resp> is not a valid child of a vanilla TEI
>     <note> element.
>   
good point. it would require a moderately ingenious
script pointed to by the <equiv> to sort that one out!
but if you can't express the relationship between
<note> and <action> using <equiv>, it's back
to <syd:action>. QED.

> Personally I'd
> like to see a controlled-vocabulary mechanism (read: attribute with
> closed list of values) for saying "born digital", just so we don't
> have to put up with all the variations:
>
>   Born digitial
>   None; this electronic document is the source
>   None. This TEI file is the source.
>   None.
>   
what attribute would this be on, and on what element?
I rather like the idea.

-- 
Sebastian Rahtz      

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

OSS Watch: JISC Open Source Advisory Service
http://www.oss-watch.ac.uk