[tei-council] Supplying default namespace with TEI Tite

[O'Donnell, Dan]

I think I agree with Laurent on choosing option c): vibrant community. Perhaps because I'm an old fogie, I don't find it esthetically pleasing. But I guess I see it as the markup equivalent of trying to driving nails with a rock when you can't find a hammer: it is ugly, probably less efficient than it could be, but something that seems to get the job done in the absence of something better. To a man with a bunch of nails, everything looks like a hammer.

In my view the 'problem' with Tite is that it arose via an unusual for us workflow: as a product of a small group of community members for a fairly specific purpose with occassional council assistance but not really council or editorial direction. The result is that people and organisations that would normally have the authority (and willingness) to take full editorial control have been unsure of their position and refinements have been made piecemeal. But this will be a situation we can expect to see more as the community takes advantage of the modification possibilities we've built in.

In terms of future work, I think council might usefully apply its energy to producing a Tite 2 at some point in the future, maybe after a year or two of the benefit. Some opportunities for improvement that I see include:
* really addressing this question of conformance
* addressing the question of keystrokes more directly: can we reduce them further?
* Situating tite more securely and explicitly in the library SIGs encoding level practices document

Doing this would involve council making candidate recommendations and circulating them iteratively around the library SIG, Perry and John Unsworth's group, perhaps some of the digitization vendors (one of whom have expressed an interest in refining Tite), and the libraries on whose customizations it is based.

But I think this might be a very good and useful thing for us to take the lead on with a timeline of maybe 2 years to completion. It would be a case study in bringing community initiatives into the fold.

-dan

-----------
Daniel O'Donnell
University of Lethbridge
(From my mobile telephone)

--- original message ---
From: "Sebastian Rahtz" <sebastian.rahtz at oucs.ox.ac.uk>
Subject: Re: [tei-council] Supplying default namespace with TEI Tite
Date: July 9, 2009
Time: 1:41:45 

Daniel Paul O'Donnell wrote:

> 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 think you're restarting an argument that we had in and around Berlin.
At that time, for whatever reason, we decided that Tite _should_
be a conformant TEI customization, in the TEI namespace. I duly
spent some time making it so. What you say above is a plausible
scenario, but it is not where we are. Tite _does_ use the TEI namespace,
and its extension elements _are_ in a different namespace.

_If_ minimizing keystrokes is the absolute priority, I don't
think Tite does a particularly good job, frankly. But thats by the by.

Sadly, Tite _stopped_ being conformant when we dropped the requirement
for a <teiHeader> :-}

> 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. 

Tite is/was an opportunity to show how one can write
extension elements and express their relationship
to core TEI using <equiv>. To that end, the ODD contains
the <equiv>, which points to the mapping code in XSL,
and you have the extensible conversion stylesheet in place.


>Of course I believe the Monk 
> project is using it as their internal language.

not sure why "of course" there :-{

I do find it strange how confused we all still are
about Tite. It's been an amazingly divisive subject ever
since it was first mooted. One can choose between interpreting
this is as

  a) a sign that the TEI world is fundamentally split
     about what its trying to do
  b) showing up the old skool rump for the dinosaurs they really are
  c) indication of a vibrant exciting community

deal or no deal?
-- 
Sebastian Rahtz
Information Manager, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

Sólo le pido a Dios
que el futuro no me sea indiferente