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

Fri Jul 21 05:09:33 EDT 2006

Sebastian Rahtz wrote:
> > James Cummings wrote:
> > I recently added tei_svg to the Exemplars set, to cover
> > than old canard of how to use SVG. I agree with James,
> > these are not just there as test files, they can be used.

Yes, another good customisation. But again, advertising these should be part of
the 1.0 release, but are in no way critical to it.  It is marketing.  :-)

> > absolutely. Although I would put a rider that
> > we mean compatibility of _instances_. If a content
> > model now refers to (a | b c)*, and we change
> > that to (%model.abc;)*, then I regard that as
> > acceptable in 1.1.

Yes, as long as 1.0 instance documents also validate in 1.1, is what I mean by
backwards compatibility.  In my mind we could introduce new modules, change the
content model of elements to a degree (i.e. replace with classes, etc.), add new
elements as long as they aren't required, etc.

> > I agree with that too. Its a matter of better error-reporting in
> > Roma, not a fundamental feature of P5 1.0

Yup, and if it is part of making the tool chain better for 1.0, then it is
desirable not essential. As long as users are currently able to use Roma (and
have access to the pre-made schemas), then making 1.0 up to scratch should be
the prime concern.

> > And agreed that the conformance chapter is vital.
> > We must re-codify what we mean by the TEI

What is a TEI P5 document?  Is it:
1) Something in the TEI namespace
2) Something with a valid TEI ODD
3) Something that validates against a schema generated from an ODD?
4) Something that has TEI and teiHeader elements?
5) Something that uses existing TEI modules and classes?

I'm still curious as to whether, if I produce an ODD that allows me to rename
all the elements I'm using to docbook-like elements whether that is a TEI
document.  Does it matter if it is in the TEI namespace?  Or if I present the
ODD with it?  The of course the question is what if I only rename 50% of the
elements, but keep some TEI ones...is that document more a TEI document?

>>> >>> 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?
> > I'd say desirable. Don't special case <body>,
> > and particularly don't let the FAND drive the agenda.
> > We do not have a mandate for that.
> > <body> is well worth a good look,
> > but if it cant be resolved, wait for 1.1

True, FAND should not drive this agenda.  I've always been a moderate FANDer
myself.  I don't like the div# element *names* but think that giving users a
structure of classes which allow a level3 class element to only appear inside a
level2 class element which in turn can only appear inside a level1 class element
is a useful data structure that is completely different from nesting un-numbered
divs.  But, along with not liking div#, I've always abhorred the div0|div1
optional starting point.  If keeping numbered divs the TEI should just decide
that it only supports div0 as a starting point... or div1 (I'm not bothered).
Did we ever make a decision on that?

That said, I assumed any major changes to the content model of body might break
backwards compatibility and mean that 1.0 documents were not valid in 1.1.  Is
this not the case?  If it is not the case, then it is only desirable and can
wait until 1.1.

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