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

[James Cummings]

While I don't have any love of the requirement to have a publicationStmt 
and sourceDesc, that they have formed a requirement for a valid TEI 
document for so long makes me want slightly more deliberation on their 
potential change to optional.  We shouldn't be making that decision 
based solely on the desire to have a really bare TEI Bare.

With any TEI document I look at these two elements often provide crucial 
bits of information: What is the availability of the document (i.e. what 
license, etc.) and is it an originally digital document or an electronic 
version of some print document or manuscript.   With the first of these 
in specific, we should be encouraging anyone creating a TEI document to 
state under what conditions it is made available.  Knowing that about 
any TEI document would, of course, be a good thing.

I'd be happy if they were optional, and thus TEI Bare could remove them, 
but I don't want Bare to be the reason for this, nor for it to happen 
without a bit of deliberation or maybe public consultation.

-James

David Sewell wrote:
> I would also be in favor of this. There are often cases where for
> teaching or testing purposes one wants to construct a valid TEI document
> instance with minimal header information.
> 
> On Fri, 5 Dec 2008, Laurent Romary wrote:
> 
>> 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
>> _______________________________________________
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council


-- 
Dr James Cummings, Research Technologies Service, University of Oxford
James dot Cummings at oucs dot ox dot ac dot uk