[tei-council] New discussion document on 1.0 release priorities

[James Cummings]

Lou's Laptop wrote:
> Syd and I have now completed a draft document outlining what we perceive
> as priorities towards the 1.0 release of TEI P5, following on from the
> discussion at the Kyoto meeting. The draft is at
> http://www.tei-c.org/Council/tcw08.xml
> 
> Council is requested to review this document, and provide input on (a)
> whether the priorities expressed in it are acceptable (b) some of the
> specific questions raised in the draft. We regard this as an important
> first step towards defining an achievable work plan.

Here are my two pence:

> Towards the 1.0 release of TEI P5 Towards the 1.0 release of TEI P5

> essential
> * New user needs to have an easy way to generate customization ODD and
> generate schemas

I'd like to also point out that the existing customisations and their generated
schemas available on the TEI website should be advertised more.  There are
people who believe that to use P5 they *must* use Roma and ODD etc. rather than
just use one of the already available schemas.  i.e.

http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng
http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/teilite.rng
http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_minimal.rng

[This just occurs to me at the point, since although we want them to have an
easy way to generation ODDs and schemas, we also want them to know that they
don't *have* to if they want to take the full tei or aren't interested in extra
constraints, lowering the barriers to use, etc.]

> After discussion and review of this list, the TEI editors now wish to present
> a revised version for Council's consideration. Note that the Editors' primary
> objective is to ensure that a usable 1.0 Release of TEI P5 is made available
> as soon as possible. We consider this to be of higher priority for the
> Council and editors than developing usability tools and tutorial guides,
> important those these are. With a stable release of TEI P5, production of
> such support materials is something that can, and will, be readily undertaken
> by many agencies. Without it, such tools can only ever be experimental.

Agreed.  One of the prime concerns is whether any of the suggestions on the
table for 1.1 would break backwards compatibility.  If they do, and are deemed
important enough they should be moved up to essential for 1.0.

> * Chapter-by-chapter review of TEI P5. This has several aspects. Although
> determining the coverage and content of each chapter is something on which
> external reviewers may well have much to contribute, ultimately it is the
> editors' responsibility to ensure that P5 appears to be an integrated and
> well-edited whole, worthy of its predecessors.

While final responsibility should lie with the editors, I feel that the council
should be helping at least in the areas of proofreading, checking clarity of
examples, etc.


> * Should P5 support the notion of module dependency? we have now introduced a
> way for a module to specify that it has a dependency on some other module
> (the depends attribute on <moduleSpec>). It is less clear how this should be
> used, or whether its usage will have an impact on the rest of P5. Input from
> Council on how much priority we should give to this question would be useful.
> There seems to have been no follow up to Sebastian's posting on the topic: so
> far, we tend to agree with his view that there is no need for this feature.

I feel that one should be allowed to create an ODD that won't produce a valid
schema, but whatever tools used to generate the schemas is where the validation
should generally be carried out.  I.e. that web-Roma should allow one to create
an ODD that would produce an invalid schema, but that when it goes to generate
the schema, that its validity should be tested.  But in generally I think this
issue is desirable rather than essential for 1.0.

> * The point at which the specification documents are frozen is probably the
> defining moment for a 1.0 release of TEI P5. The licence we have given
> ourselves to break backwards compatibility will be revoked at that point. In
> other words, although we expect further development beyond 1.0, this will
> have to be done without breaking either existing documents or existing
> schemas. Obvious exceptions to this general principal include fixes to
> egregious errors, and changes caused by corresponding changes in an external
> specification. This and related issues need to be explored in the Conformance
> and Modification chapters. Revision of those chapters should therefore, in
> our view, be given a higher priority than it currently enjoys.

Agreed. These should be essential.  As TEI is making it easier and easier to
produce ODDs for TEI documents which increasingly differ from other TEI
documents I feel the community is going to worry about the increasing
fragmentation and dispersal of what they view as a TEI document.  They like to
be able to conform to a standard, and funding bodies like the sound of that as
well.  If one writes an ODD that completely renames and reshapes every TEI
element, and introduces lots of new ones, and ends up looking exactly like, say,
docbook, people are going to want to understand how that is still to be
considered a TEI document.

> * Earlier this month, we learned that the original author of the Terminology
> chapter (Alan Melby) is keen to take on the task of revising it, which has
> been long in abeyance. This is, obviously, very desirable; however, as with
> the Physical Bibliography chapter, we do not feel that release 1.0 of P5
> should be delayed waiting for it to happen.

Is it likely that the changes Alan will want to make significantly break
backwards compatibility?

> Desirable
> * Feature Requests: as noted above, we consider a review of outstanding
> feature requests to be essential. It is also desirable to confirm with all
> those who sent in such requests that they are aware of how we have resolved
> the issue concerned and are at least not very annoyed about it.

And if the person(s) are quite annoyed that it hasn't been resolved in a way
they want?

> * By "missing examples" we understand the need to ensure that all chapters
> adequately illustrate the features documented. This is part of the Chapter
> review process.

> * Inclusion of the new material on Physical Bibliography just received is
> classed here as desirable rather than essential, largely because we don't yet
> know how much work is entailed in making it compatible with the rest of the
> Guidelines. It seems likely that much of it will be useful as providing (a) a
> specific illustration of how to do stand off markup (b) a specific
> illustration of how to define a radically different schema based on the
> physical rather than the logical organization of a codex.

I think that the material should be assessed, if possible, to see how
problematic it would be to make it compatible with the rest of the Guidelines.
Especially if the changes suggested break backwards compatibility if delayed
until 1.1.

> * The deliverables from the Personography activity have now been integrated
> into P5, but will need a considerable amount of further work as a part of the
> Chapter review process. It has been suggested that it would be desirable to
> expand the treatment of placenames in a similar way, so that gazeteers and
> similar sources of geographical metadata could be handled in a way analogous
> to the way that biographical data is treated. Council's opinion on that would
> also be useful.

I would like to see listPerson, person, etc. in P5 1.0, and think that the
writing of related prose and reviewing of it should be given a higher priority.
 I do not think, at this time, we should worry about necessarily getting
listPlace, place, or whatever into 1.0, and that this will wait just fine until 1.1.

> * In Kyoto, revision of the chapter on Text Criticism was regarded as
> desirable, but we are not aware of any activity currently aiming to produce
> such revisions, nor of what exactly needs changing. If Council wishes to
> sponsor or promote such a revision, this will need to be set up very soon.

I can't remember why we wanted it revised either.  Was it to indicate the
relationship between app and choice?

> * Minor revision of some aspects of the Feature System Declaration chapter is
> likely to take place over the next couple of months as a result of the
> continuing ISO/TEI liaison.

I agree that this is desirable but not a block for 1.0.

> * Completion of revision of the chapter on handling multiple hierarchies is
> also highly desirable: the material currently in P5 is very dated, and
> although new material has been received it has yet to be integrated with it.

I think this should be more than desirable, but essential.  Overlapping
hierarchies has been such a hot topic over the last few years.  And I've
encountered people mistakenly avoiding using XML because of their perceived need
for multiple hierarchies.  (In most cases this has been more a result of
ignorance...)  So my reasons for wanting this in 1.0 is less to do with
technical realities, but more to do with the perception of the TEI as solving
these problems as a community-led standard.

> 1. The content model for <body> needs review with an eye towards better use
> of the class system. In particular, it would be desirable to be able to
> remove elements (including numbered <divN>s) without producing ambiguous
> content models

Essential?  Would this break backwards compatibility in 1.1?

> 2. Should <note> be a global element? If so, how?

I think it should be global under the text element, and only selectively
available in the header.  I think this change (or something like it) should be
essential for 1.0 as a reaction to the community's support of it.  Another
option is to have note as a general element, but produce specialised syntactic
sugar versions of this for use in certain contexts.  (But I'm not sure I think
that is a good idea.)

> Related to this, there is a
> need for a grouping element which can associate any of some identifiable
> number of metadata elements with an annotation or comment. We could do this
> by something like the <assertion> element proposed originally in the
> Personography exercise; other possibilities include the introduction of a
> special mechanism to allow for <xxxGroup> elements for each <xxx>; a
> special-purpose pointer attribute; and a special-purpose <link> element.

I think this is desirable, but as it might take awhile to get it right should be
slated for 1.1.

> 3. Application-specific Information needs a home in the header. There is a
> proposal in SF for this, but it is very specific to one type of application
> and needs to be generalised.

Desirable for 1.1.

> 4. Definition of an appropriate content model for "anorexic prose" in the
> header. See my (as yet uncommented on) note of 10 June to council with
> subject line "Reduced phrase proposals".

In answer to your questions in that email (which I did comment on, albeit briefly):

1) I thought it was:
model.pPart.edit.choice = choice app
model.pPart.edit.transcribe = add damage del restore space unclear
model.pPart.edit.editorial = abbr corr expan orig reg sic supplied

and that .editorial should really be broken up so that you could use abbr/expan
in the reduced header phrase  but not the others.  I have no use case for using
choice inside header elements, and don't remember that really being the
suggestion. (But again, my memory is fuzzy).

2) Is it that the others are really more emph-like than hi-like?  I can see
wanting to use foreign/gloss/term/etc in the reduced header phrase class, but
less so 'hi' (or distinct).

3) Agreed.

4) I think the argument was that code and ident are emph-like in many use cases.

> 5. Definition of a specific solution, or at least decisions as to best
> practice recommendations, for the inclusion of SVG in a TEI document. This
> may or may not be the same as that old chestnut about how to handle TEI
> documents which consist of page images, or how to align page images with page
> transcripts, or how to do detailed image annotation in TEI as per Victorian
> practice.

Desirable for 1.1.

> 6. How to handle regularisation of names, without recourse to persons.

Desirable for 1.1.  Using persons isn't too much overhead if seriously needing this.


-James


-- 
Dr James Cummings, Oxford Text Archive, University of Oxford
James dot Cummings at oucs dot ox dot ac dot uk