Re: error in description of teiCorpus

Hugh Cayless <[email protected]>
Newsgroups gmane.text.tei.general
Message-ID <CAObhq+dLKBq63XinPdoLwMTszRFWATf+KmK1o5FAuGOFwZH5rg@mail.gmail.com>
It does look like we blew it on this one. Sebastian had a use case in mind
and made the change to the content model without bothering to change the
documentation. Looking at the original request, I have some sympathy for
it, but I'm not convinced that it was the right way to solve the problem.
Oh well...

We do try to keep the Guidelines prose and the ODD documentation in sync,
but sometimes we fail. I'd like to think that nowadays, this sort of thing
wouldn't proceed without discussion and input by the whole Council, which
would mean it would get handled properly.

We'll have to try to sort out a sensible approach to dealing with this.
Thanks for bringing it to our attention!

Hugh

On Wed, Feb 15, 2017 at 12:46 PM, C. M. Sperberg-McQueen <
[email protected]> wrote:

> Fine with me; I hold no brief for my proposed wording, which I gather
> is based on a misunderstanding of what a series of facsimile, fsdDecl,
> sourceDoc, and text elements appearing as children of teiCorpus are
> intended to be.  I’ll leave the task of formulating wording to those
> who understand the intent, which despite Lou’s explanation I don’t.
> Examples might help.
>
> This may be a bigger problem than I realized at first.
>
> Right now the function of fsdDecl, facsimile, sourceDoc, and text as
> children of teiCorpus appears to be undocumented except in the
> feature request to which Lou points; the descriptions of teiCorpus
> (and language corpora in general) in chapters 15 and 4 of the
> Guidelines say nothing about them, except to describe the teiCorpus
> element as one teiHeader element followed by a series of ‘TEI’
> elements, which entails that those elements are invalid as
> children of teiCorpus.
>
> It looks as if what was discussed and approved and implemented
> was not a complete self-contained proposal that changes the
> Guidelines from one self-consistent state to another self-consistent
> state, but a proposal that entails an unspecified number of knock-on
> changes to be worked out later: a promissory note with neither
> amount nor due date filled in.
>
> Perhaps those responsible for the maintenance and development of the
> Guidelines should do as some standards development groups do, and
> require that change proposals not introduce new contradictions into
> the spec.  At a minimum, that means that if the change proposal calls
> for changing the content model of an element, it also calls for
> wording changes to every description of the element which reflects the
> old content model but contradicts the new one.  Such a requirement has
> the drawback of making it harder to prepare change proposals, and it
> would make the process feel heavier and slower.  That's probably a
> drawback.
>
> But given that an interested user cannot now find out what a
> /teiCorpus/facsimile element is supposed to mean or be, how much good
> was achieved by the change to the content model?  Presumably those who
> proposed the change are now able to use it while making their corpora
> valid according to a vanilla TEI schema.  But since it's not possible
> for a consumer of those corpora to find out what some things mean, we
> seem to have lost one of the key promises to consumers of TEI-encoded
> texts, which is that in any TEI-conforming document the meaning of the
> markup language must be documented: either in the Guidelines, for
> TEI-defined elements, or in the ODD file, for extensions and
> modifications.
>
>
> Good luck,
>
> Michael
>
> > On Feb 15, 2017, at 10:03 AM, Lou Burnard <[email protected]>
> wrote:
> >
> > It's true that the description doesn't match the content model now
> permitted, but I am not sure that I like your proposed rewording, since
> "one or more elements representing part of the corpus" seems to contradict
> the use case which led to Council agreeing this change back in 2013 (see
> https://sourceforge.net/p/tei/feature-requests/456/). My reading of that
> discussion is that any model.resourceLike element which is a direct child
> of teiCorpus should represent the whole of (some aspect of) the corpus,
> which is not quite what the suggested phrase connotes.
> >
> > On 15/02/17 16:26, C. M. Sperberg-McQueen wrote:
> >> The gloss of the teiCorpus element reads
> >>
> >>     <teiCorpus> contains the whole of a TEI encoded corpus,
> >>     comprising a single corpus header and one or more TEI
> >>     elements, each containing a single text header and a text.
> >>
> >> This was a true description in TEI P3 and TEI P4, but at
> >> some point the content model was changed.  What follows
> >> the header is no longer a sequence of ‘TEI’ elements
> >> (and since the vocabulary can be modified, it is also not
> >> necessarily a sequence of elements defined by the TEI,
> >> so not necessarily ‘TEI elements’ in that sense).
> >>
> >> The gloss should probably be changed to avoid stating
> >> a falsehood.  Perhaps it would do just to say
> >>
> >>     <teiCorpus> contains the whole of a TEI encoded corpus,
> >>     comprising a single corpus header and one or more
> >>     elements representing part of the corpus, some of
> >>     which may be teiCorpus or TEI elements with headers
> >>     of their own.
> >>
> >>
> >> ********************************************
> >> C. M. Sperberg-McQueen
> >> Black Mesa Technologies LLC
> >> [email protected]
> >> http://www.blackmesatech.com
> >> ********************************************
>
> ********************************************
> C. M. Sperberg-McQueen
> Black Mesa Technologies LLC
> [email protected]
> http://www.blackmesatech.com
> ********************************************
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.