[tei-council] customization in P5

[Laurent Romary]

As a matter of fact, a whole week of meetings, ending in a full  
afternoon of Roma/ODD tutorial in Nancy at the very time of our  
conference call put me in the best position just to forget it... I  
should send tankers of apologies to all of you, but Lou's message  
cheers me up a little bit since I can give you a kind of feedback  
from the mass. It appears that the principles of ODD, combined with  
the nice features of Roma do reach people's mind as we teach them. My  
audience was made of colleagues from Nancy who, for most of them, had  
experience of DTDs/Schemas and the like. They al appreciated the  
prospect of not having to fiddle with those things anymore and are  
very pleased with the idea of just having ODD as the sole  
custumization means for the TEI (or sole specification language for  
any kind of XML application, but this is rather out of topic).
So I would like to suggest that the council fully endorses the  
proposition of the Meta group that we highly recommend not to hack  
DTDs/Schemas for customize the TEI tagset, but ony use ODD specs. I  
then agree to put the issue of defining what an ODD conformant  
processor is on the agenda of my meeting with Lou next week.
Best wishes,
Laurent

PS: the DTD which is generated when deleting  a lot of elements from  
the 4 basic module (e.g. just to keep text/(front,body,back)/p) is  
not as robust as the corresponding RelaxNG schema). Incomplete  
stements are generated which prevent any further processing.



Le 18 déc. 05 à 19:49, Lou's Laptop a écrit :

> At present, there are two ways in which I can make a TEI schema.  I  
> can either write an ODD and crunch it through the appropriate  
> stylesheet, or I can hack together an invocation of the relevant  
> modules using constructs specific to my chosen schema language  
> (e.g. a DTD subset for DTD language or a RelaxNG schema with  
> rferences to the right patterns) .  The constructs I use are quite  
> different for different target languages, especially if I want to  
> delete or emend elements or add new ones.  In P4, much of chapter  
> ST is given over to explaining how  the customization mechanism is  
> implemented in DTD world, but there is no discussion at all about  
> how I might combine RelaxNG modules. And I don't have the faintest  
> idea how I'd do it in W3C schema, before you ask.
>
> As I go about revising this chapter, I keep wondering whether or  
> not any of this is still needed. If our recommendation is (as I  
> think we agreed in Paris that it should be) to express each TEI  
> customization declaratively as an ODD, why should we bother people  
> with x.entities and things  like <!ENTITY  % TEI.wibble  
> "INCLUDE"> ? If you run your ODD through the appropriate  
> stylesheet, what you get out is a flat schema in the target  
> language, not one that  invokes a set of modules at all. It uses  
> lots of parameter entities, but they are not the ones defined in  
> chapter ST.
>
> Some time ago, the Meta group noted that if  we continued to   
> support modifiable DTD fragments, we would have to find some way of  
> round-tripping between a TEI DTD modification subset and the  
> corresponding ODD. This was not something we wanted to contemplate  
> at the time, nor does it fill me with enthusiasm at the moment.  
> Neither does the thought of maintaining  multiple ways of doing the  
> same TEI customization independent of each other.
>
> I don't have an answer to this and it raises difficult problems. If  
> we say that the only means of TEI customization supported is via an  
> ODD spec we need to put more thought into specifying exactly what  
> an ODD conformant processor does. If we say that there are many  
> means of customization, we need to explain all of them in quite  
> some detail. Hmmm.
>
>
>
>
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>