[tei-council] Supplying default namespace with TEI Tite

[Daniel Paul O'Donnell]

James Cummings wrote:
> 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 availabl TEI Tite -> pure TEI 
> stylesheet out there, I'm happy to write one.
>   
Actually James, that would be absolutely superb. The point behind Tite 
is that it is a temporary workflow stage that can then be converted 
directly to TEI. It's non-conformancy is a pure artefact of the intended 
use case (keyboarders paid by the character). Tite is not namespaced for 
purely economic reasons: there is no intellectual objection to <t:i>; 
the economic objection is that it increases the cost of the tag by 60%.

I also think the rest of your observation is excellent here: Tite is an 
opportunity to show how you can customise things and ought to be a 
teaching moment in terms of explaining to people why they should see it 
only as a stage in a workflow rather than an archival format. A sheet 
converting to TEI would really help emphasise that and we could edit the 
documentation to really emphasis this. Of course I believe the Monk 
project is using it as their internal language.

If you wanted to do a stylesheet, I could write up some even more 
explicit language for the narrative.
> -James
>
>   

-- 
Daniel Paul O'Donnell
Associate Professor of English
University of Lethbridge

Chair and CEO, Text Encoding Initiative (http://www.tei-c.org/)
Co-Chair, Digital Initiatives Advisory Board, Medieval Academy of America
President-elect (English), Society for Digital Humanities/Société pour l'étude des médias interactifs (http://sdh-semi.org/)
Founding Director (2003-2009), Digital Medievalist Project (http://www.digitalmedievalist.org/)

Vox: +1 403 329-2377
Fax: +1 403 382-7191 (non-confidental)
Home Page: http://people.uleth.ca/~daniel.odonnell/