[tei-council] update from the TEI Tite task force: comments on 2 tickets by October 1

[James Cummings]

On 19/09/11 14:36, Kevin Hawkins wrote:
>> I am not sure what to say. If the Tite users want<add>   and<del>,
>> sure, go and ahead and give it to them. I am not sure how we can
>> help you decide this? If Tite plans to cover hand-written material,
>> I personally think that's such a huge extra burden that
>> the advantages of a standardized Tite are negligible. I think
>> I'd prefer a TiteMS, which is Tite + Handwrititing, rather than
>> giving<add>   and<del>   to the vast majority of Tite users. But
>> that's Tite politics, not a technical question.
>
> Right, well, here's my situation.  Tite has fallen under the stewardship
> of Council, so I feel like there should be a consensus (or at least a
> majority) of Council members supporting any change to Tite.  You might
> not have a use case for Tite, so it's fine with me if you abstain, just
> as I'm largely doing from our recent discussions of the proposal on
> genetic editions.  I know I asked for feedback on these tickets in
> February, but I hadn't responded to Sebastian's comment until after that
> date, so I wanted to give others a chance to review it before I consider
> there to be no objections.

I think Kevin is right to ask here since, as he says, Council now 
has stewardship of Tite. I agree with what I believe Lou and 
Sebastian have said.  Though there may have been  a desire for 
vendor encoding of manuscripts, this comes with so much overhead 
that makes Tite as it is unsuitable. (I.e. if we were making 
TiteMS then there are a lot more things I'd add rather than just 
add/del.)  I would suggest that where manuscripts are concerned a 
bespoke customisation be agreed with the vendor (this could be 
Tite + add/del, or entirely different). I think the answers for 
the @facs question already sufficient.

Partly (not to try and influence answers to John Unsworth's 
question 6d), I am highly resistant to Tite becoming seen as 
being what the TEI is about. I agree that it is great for 
streamlined production in a mass-digitization environment, but 
firmly believe that it should *never* see the light of day. i.e. 
that it should always be transformed, almost immediately, 
internally to the project and only ever proper TEI exposed to 
anyone outside the project. My primary reason for feeling so 
strongly about this is the ways in which Tite breaks the TEI 
Abstract Model and my worry that if we expose lots of TEI Tite 
people will come to think that is "The TEI" the same way I 
encounter lots of people who think TEI Lite is "The TEI".

As a side note, I've hypocritically just done something similar 
myself with a byte-reduced schema called tei_corset.  This is for 
a vendor who for some inane reason is charging per kilobyte of 
output yet doesn't mind working to a highly compressed schema. 
Hence in the tei_corset ODD <name> becomes <n> and @rend becomes 
@r and @type @t and <div> <d> etc. Although and extremely 
inefficient form of compression it has resulted in almost 40% 
reduction in filesize. It has also been reduced to about 35 
elements.  However, even in that I require renamed header and a 
title, making it much more TEI-Conformable. ;-) It will be 
expanded to full TEI Conformant version before the project 
researchers ever see it, it is solely a cost-saving exercise.

-James

-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford