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

[Daniel O'Donnell]

As much as I'd like to say "see, it really is all div, seg, ab, and
list" (and of course crow that the TEI/ISO work is showing that I was
right about Word as the gold standard), I agree with James in that
source and publication statement are part of what separates a TEI
document from any old pre-html 2.0 document. It seems a not overly
burdensome addition to the minimal set and what makes a document a
document in a controlled way rather than just a collection of text.

When I teach TEI, I get them used to the idea that _coding_ need not be
burdensome using basic quirks-style html (i.e. without bothering about
doctypes); then gradually move up showing how a little bit more effort
achieves greater and greater precision and usefulness. I'd say these two
elements might mark the line at which you are crossing from barrier from
"get it working in a webbrowser" to "give me a document that means
something bibliographically."

On Fri, 2008-12-05 at 15:17 +0000, James Cummings wrote:
> 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
> 
> 
-- 
Daniel Paul O'Donnell, PhD
Associate Professor of English
Director, Digital Medievalist Project http://www.digitalmedievalist.org/
Chair, Text Encoding Initiative http://www.tei-c.org/

Department of English
University of Lethbridge
Lethbridge AB T1K 3M4
Vox +1 403 329-2377
Fax +1 403 382-7191
Email: daniel.odonnell at uleth.ca
WWW: http://people.uleth.ca/~daniel.odonnell/