[tei-council] TEI Conformance

[James Cummings]

Sebastian Rahtz wrote:
> 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

I would be interested to know why, so maybe if you could think about this.  I
understand there are some _difficulties_, but none that I could think of which
were deal breakers.  It just seems like the 'right thing to do' in reading about
how the W3C views namespaces.  And if people were to add their entirely new
elements in a different namespace, then it also makes sense for TEI to suggest a
namespace for this (rather than every user come up with one).  I'm in no way
suggesting this change should be taken lightly (but we shouldn't just dismiss it
either).

>>         <syd:ps>If I weren't so cold I would have thought of
>>         something funny</syd:ps>
> depends whether <ps> can be <equiv>ed or not, doesn't it?

Looks like <ab type="postscript"> or something to me. ;-)  I think the point
with this is that a large portion of the customisations people undertake really
are the creation of TEI equivalent structures.  glist for list/@type'gloss',and
your ps, and similar. Do they have requirements not embodied in the TEI elements
they are equiv'ed to?  I think the interesting aspect is how to define when
someone shouldn't be using equiv and should instead be adding an entirely new
element.  Is it that a renaming is a further constraint on the semantics of an
element?  I.e. is <email> a specific type of <addrLine> ?  If it isn't, then one
shouldn't equiv to 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 :-}

In giving advice on behalf of a funding agency to those wishing to use P5, I
have said that what they should do is provide a TEI ODD file as documentation to
any customisations they make to the TEI.  I have not mentioned what types of
customisation should be allowed in that ODD file, nor what namespaces should be
in use, etc.  I would highly doubt that a funding agency would go this far.  I
can see them (mistakenly in my view) saying the preservation copy must be a Pure
Subset of tei_all or something.  But I don't think this is something you should
be very worried about (only mildly concerned).  Besides, if the TEI were
providing a TEI Extensions namespace, then it would be a TEI namespace and thus
satisfy your picky funders. ;-)  Funding agencies are now starting to suggest
the TEI as a recommended format, something we should encourage and capitalise
upon, but I don't think they will get draconian about the details.

>> 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?

Yes, for the record, I don't in any way want to discourage modifications and
extensions.  On the contrary, I want to encourage them by defining them as TEI
Conformant if done in the appropriate manner.

>> * 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.

Yes, that was my intention.  If something is reversible with reference to the
<equiv>, then it is a form of renaming.  If it isn't reversible, then it is an
extension or modification.


>>   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]

If the renaming were reversed, and the <action> became <note type="action">,
would it validate against tei_all?  If so, then it should be listed as an equiv
because you are creating a pure subset of tei:note by restricting the content
model even further (if and only if name/resp/date are all allowed in tei:note.),
and then renaming that pure subset.  If that is the case, then it should be a
renaming and documented with <equiv>.
>> [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.

Ah, so that isn't the case. (Now, I could go and edit my text above, but that'd
be cheating.)  In this case then yes, tei-ext:action is not a pure subset of
tei:note, so this is renaming+modification which really is just 'extension'.  So
yes, it should be added in the TEI Extensions namespace.

>> 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.

Hrmm. On sourceDesc as an alternative to content? Tricky.


-James

-- 
Dr James Cummings, Oxford Text Archive, University of Oxford
James dot Cummings at oucs dot ox dot ac dot uk