[tei-council] Supplying default namespace with TEI Tite

James Cummings James.Cummings at oucs.ox.ac.uk
Tue Jul 7 05:00:47 EDT 2009


Lou Burnard wrote:
> Sebastian Rahtz wrote:
>> there are
>> three choices, if Tite needs those extra elements
>>
>> 1. add them to the core TEI
>> 2. add them in their own namespace, as per guidelines
>> 3. add them to same namespace as the rest and thus make Tite nonconformant
>>
>> there are no magic bullets, unless you think I misread conformancy...
>>
> I agree with the formulation of the choices tho. I don't like the third 
> one at all. The second one seems perfectly OK. The first one might also 
> be OK, but the case has not been made.

I think Tite is fine as it is -- or at least I certainly wouldn't want 
to start mucking about with it unnecessarily.  (Part of the point being 
to produce something stable that vendors can use!)

I think Tite serves an additional function as well, which is pedagogic. 
  It is an example of a customisation which includes syntactic sugar 
elements in their own namespace.  I think that is a *good* thing, and 
don't see why vendors would complain about <t:i>.  Multi-namespace 
validation is pretty straightforward these days and <t:i> is a lot 
easier for them than <hi rend="italic">.

I'm of the opinion that either the vendor or the project should be 
post-processing <t:i> back to pure TEI <hi rend="italic"> (or whatever) 
rather than keeping the files in Tite.  I think it would be a failure in 
educating users (about the intent of Tite and the convenience elements) 
if they did not do this.  If anyone (other than digitisers) is using 
Tite in a production system then I think we are failing in our duty to 
educate.  If we don't have a publicly available TEI Tite -> pure TEI 
stylesheet out there, I'm happy to write one.

-James

-- 
Dr James Cummings, Research Technologies Service, University of Oxford
James dot Cummings at oucs dot ox dot ac dot uk


More information about the tei-council mailing list