[tei-council] Conformance .... the continuing saga

[Daniel O'Donnell]

I think also that the issues are getting fine enough that it may be
difficult to have a strong opinion: personally I think I am an a and c
person in Christian's formulation: ODD as the recommended standard,
footnote or whitepaper on RNG, and drop the DTD for P5. I also suspect
from conversations I've had that we are likely to see a legacy of P4
projects for quite a while--especially institutional ones--so, I'm happy
dropping the dtd business for conformance for P5 anyway.

As to ODD processors--I've no informed opinion.

On Fri, 2007-04-06 at 10:21 +0900, Christian Wittern wrote:
> Sorry, folks -- this seems to have gone only to LB, not the Council list 
> where it was intended to.
> 
> Christian
> 
> 
> Christian Wittern wrote:
> > Lou Burnard wrote:
> >> Does no-one else on the Council have a view on this issue? Or is 
> >> everyone already on holiday?
> > 
> > We are a global organization, so you should at least let pass 24 hrs 
> > before any cry of desparation.  But I agree that we need more input on 
> > this important matter.
> > 
> >>
> >> Personally, I am reluctant to remove parametrisable schemas without a 
> >> bit more consultation. I have no problem with saying that true TEI 
> >> conformance necessitates production of an ODD. But I still feel we 
> >> have an obligation to make it feasible for people to customize the 
> >> system without using tools that only we provide. Which means that we 
> >> need to continue to provide customizable fragments, and describe how 
> >> they can be used. We *want* people to use TEI P5 at whatever level 
> >> they feel comfortable, right? 
> > 
> > Maybe its survey-monkey time again?
> > I remember us saying that we will continue to maintain P4 for those who 
> > need it for some reason, but will pipe new developments into P5 without 
> > too much consideration for how this will brake peoples *current* 
> > systems.  Well, this was some years ago.
> > 
> > With P5 now so deep into namespaces, data validation etc., we have moved 
> > pretty much away from things possible in DTDs.  Because of editing 
> > support, we should continue to offer pre-a-porter DTDs for those who 
> > don't want to dress up, but I do not think we should continue to support 
> > the customization mechanism of P4.  If we do not let go of this now, it 
> > will be a big headache down the road, since we stopped ourselve from 
> > removing it later in the P5 product cycle.
> > 
> >> For people still in DTDworld, the old method of stitching together DTD 
> >> fragments is just fine, and they can go on doing it without having to 
> >> learn any of this newfangled namespace stuff. 
> > 
> > We will do them a mis-service.  They will want to grow up and live on 
> > equal footing in XML-Land, so they need to wrap their heads around this 
> > stuff.  We should mildly encourage them to do so.
> > 
> >> People who, by contrast, are hip to the RelaxNG groove will want to 
> >> know how to plug TEI stuff into their production line without having 
> >> to completely revise the whole shooting match. So my preferred course 
> >> of action would be:
> >>
> >> 1. Revise MD to make explicit that there is more than one way of 
> >> building a schema from the TEI Guidelines. In fact there are three:
> >> (a) write an ODD and process it with a conformant ODD processor
> >> (b) write a DTD subset using parameter entities and ting and ting
> >> (c) write a Relaxng schema which combines TEI RelaxNG modules ad lib
> > 
> > My course would be: do (a), forget about (b) and either mention (c) in a 
> > footnote or point to some white paper on the TEI website that explains 
> > how to do that, clearly marked as advanced material.
> > 
> >> 2. Of these ways, only (a) is guaranteed to result in a schema which 
> >> can be used to validate TEI conformance for your documents, but the 
> >> others may be helpful for local use. So we provide suggested ways of 
> >> doing them, in two distinct subsections of the document.
> > 
> > Hmm.  I read the I in TEI as Interchange and think it is not really our 
> > business to think about what people should or should not do in the 
> > privacy of their own hard-drives.
> > 
> >>
> >> 3. We need, urgently, a definition of what exactly a "conformant ODD 
> >> processor" is supposed to do. This might include a description of what 
> >> the current ODD processor does, but that is less important.
> > 
> > Hopefully Sebastian thinks about this while we speak.
> > 
> >>
> >> If, on consultation, it is apparent that no-one cares about (2) above, 
> >> we can always throw away the lovingly-crafted prose I expect to be 
> >> generating this weekend, or put it somewhere else... but I think we 
> >> must have the consultation.
> > 
> > So maybe you could use your time to attend to other pressing matters and 
> > produce the prose once we reached agreement over this?  I think that 
> > would be better use of our scarce ressources.
> > 
> > All the best, "no holidays in sight" Christian
> > 
> > 
> 
> 
-- 
Daniel Paul O'Donnell, PhD
Director, Digital Medievalist Project http://www.digitalmedievalist.org/
Associate Professor and Chair, Department of English
University of Lethbridge
Lethbridge AB T1K 3M4
Canada
Vox: +1 403 329-2378
Fax: +1 403 382-7191