[tei-council] Proposal <idno> coverage -SF 2493417

[Lou Burnard]

Whether or not we support DTDs in ODD3, we need to find a good solution 
to the bibl/Struct problem. It might be a good idea to start by stating 
that problem more clearly. I think the major issue  is that the 
wholesale application of Occam's razor has led the TEI to treat 
bibliographic descriptions which are being created and managed ex nihilo 
(e.g. in a header or bibliography) in exactly the same way as things 
that we wish to read as bibliographic descriptions when they appear in 
an existing text (e.g. a bibliography which is being transcribed rather 
than created). In either case we offer a choice between <bibl> and 
<biblStruct> the only difference between which is that the latter 
constrains some sort of order on its children -- but they are the same 
unruly bunch.

If we decided that <biblStruct> was for the ex-novo-case, and <bibl> was 
for the other one, we could separate them a bit better. For example, we 
might say that <author> only made sense in <biblStruct> and that <bibl> 
should instead offer only <name>. We could reorganize the current 
model.biblPart class, distinguishing those which we permit inside 
<biblStruct> and those which we do not.

However, this is not going to be an easy job. And I think it needs input 
from a more substantial group of TEI and library users than we've so far 
managed to muster to focus on it.

It might lead us to think that "conditional content models" are a sine 
qua non; it might not. Let's not get too excited about the technical 
aspects just too yet...

Sebastian Rahtz wrote:
> Laurent Romary wrote:
>> After some thoughts, I would definitely favour this. It worries me that 
>> we should have separate elements for expressing the same thing, just 
>> because the encompassing structure imposes separate constraints. So yes, 
>> we need alternate content models.
> 
> the BIG problem with this is that ODD does not allow
> for it. moving in such a  direction means starting the transition
> to ODD version 3, which would (among other things) remove DTDs.
> 
> the alternative being to embed all the intelligence in Schematron;
> which would work, but is likely to remains a minority activity.
> 
> but if we decided strategically that alternate content
> models is the future of the TEI (and it has a lot of attractions),
> then it could be a target for this year.
> 
> Syd may be forgiven for saying "I told you so..." over and over....