[tei-council] Supplying default namespace with TEI Tite
Daniel Paul O'Donnell
daniel.odonnell at gmail.com
Wed Jul 8 20:36:59 EDT 2009
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.
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/
More information about the tei-council