[tei-council] Making absolutely bare a little more bare

[Laurent Romary]

As a matter of fact, if the TEI content model would permit it (but it  
does not at present) I would also drop publicationStmt and sourceDesc,  
so that I could actually have a very focused pedagogical tool to  
demonstrate valid examples such as the one below. But are we just  
ready to make publicationStmt and sourceDesc ... well, euh, optional?

Le 5 déc. 08 à 11:17, Lou Burnard a écrit :

> I think these "survivors" come from two sources:
>
> (a) elements introduced after the ODD spec was written (e.g.  
> postscript) won't
> have been deleted from the spec. This is one of the interesting  
> consequences of
> the way ODD works...
> (b) at one point in time, the view was that you should not permit  
> customisation
> of the TEI header.
>
> I entirely agree with Laurent that a really bare teibare would be  
> useful.
> I am quite tempted by the idea that it might not even require a  
> Header, but that
> may be a step too far.
>
>
> message <176C96B9-6BE3-448A-A369-BE5D6BAADF63 at loria.fr> Laurent Romary
> <laurent.romary at loria.fr> writes:
>> I did. And doing so discovered a few other candidates for deletion.  
>> So
>> the victims so far are:
>> <editionStmt>, <extent>, <seriesStmt>, <postcript>, <biblFull>,
>> <notesStmt>, <typeNote>, <postcript>
>>
>> I am still wondering why we managed to keep all these...
>>
>> Le 4 déc. 08 à 14:26, Sebastian Rahtz a écrit :
>>
>>> Looks fine by me. Have you tested whether it works
>>> without them? possibly some hard-wired dependency
>>> which is why we left them in? (if so, we should track those
>>> down)
>>>
>>> -- 
>>> Sebastian Rahtz      Information Manager, Oxford University
>>> Computing Services
>>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>>
>> _______________________________________________
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council