[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