[tei-council] Tite and conformance (long)

[O'Donnell, Dan]

Well,  I think you'll see if you read my emails that I'm against rewriting the conformance section of the guidelines on this. Partially because I was a strong advocate of it in its current form, as I remember.

So, as I've been saying, the issue is fixing Tite to avoid doing deprecated behaviour. If this involved fundamental changes, then I'd say that we need to let it go for now: Tite does what it is supposed to and as James and David have pointed out we all know that it is only supposed to have a very short existence for a very brief period in a workflow. Given the instruction we have received from the board, the state of play of the tender process for a digitization benefit, and the fact that tite is an amalgamation of already existing practices, we'd just have to live with it for now.

But I've been suggesting that fixing Tite, or at least removing the main places where it does what we actually recommend against, may not be that hard.

I don't think at this stage that we need to re-require the header. We can live with an extension that is not algorithmically conformable given that the non-algorithmic change required is quite straightforward. In Tite 2.0 we might want to revisit that decision, and require a minimal header. But we can live with it in its current state.

The really serious issue from a theoretical perspective is the namespacing. It is easy to decide not to sweat this, since the renaming is trivial, but given how much we want to deprecate the practice of including non TEI elements in a TEI namespace, I think we need to do something in order to set a good example.

My ideal solution would be something that allowed us to identify specific elements in a TEI document has belonging to a particular namespace (so for example, maybe something in the encoding statement that allowed us to say 'all tags <foo> should be understood as myns:foo unless a particular instance has an explicitly different namespace associated with it.'). That would solve this problem neatly and immediately and provide a useful mechanism. But it is a bigger change than we should make right now to P5.

So the other approach I'm suggesting is that if Tite doesn't want to explicitly declare namespaces for its convenience elements, then the whole thing has got to be in a different namespace, formally speaking--including the elements that are actually straight copies of the canonical TEI ones. In other words, I'm suggesting that Tite may not belong in the TEI namespace at all, if it can't otherwise distinguish among its canonical and non-canonical elements. I think a namespace hawk like Conal would agree with this.

We have already envisioned a circumstance where this kind of thing happens with namespaces: internationalizations. Or at least I think so. This is why I asked how an internationalization would handle elements that have identical names and structures in the target language and the canonical namespace. If a Dutch customisation, for example, renamed <emph> to <nadruk> and <p> to <alinea> but used <div> for TEI div, which elements would show up in the special dutch namespace (tei-c.org/ns/1.0/nl name space)? nadruk and alinea but not div or all three? AFAIK all three would.

If this is right and all three would show up in the nl namespace, despite the fact that nl:div is a clean copy of tei:div, then the answer to the Tite problem is pretty straightforward: put the whole thing in its own namespace: tei-c.org/ns/1.0/tite/1.0. That allows us to avoid a practice we strongly deprecate, emphasises how serious we are about asking people not to pollute the canonical space, and is an defensible reflection of what Tite actually is.

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

--- original message ---
From: "Lou Burnard" <lou.burnard at oucs.ox.ac.uk>
Subject: Re: [tei-council] Tite and conformance (long)
Date: July 9, 2009
Time: 4:11:23 

O'Donnell, Dan wrote:

> The reason for worrying about this is that we are promulgating Tite and considering as the basis of what will be a very high profile benefit. It is bad policy to promulgate something that has aspects that we strongly deprecate in our guidelines (i.e. The namespace issue).

I'll drink to that. So  do you want to change the whole structure of the 
Guidelines' recommendations on conformance issues, arrived at after not 
a little effort, and  protracted debate? Or how about reconsidering the 
hastily taken decision to "promulgate" something which is clearly broken?

_______________________________________________
tei-council mailing list
tei-council at lists.village.Virginia.EDU
http://lists.village.Virginia.EDU/mailman/listinfo/tei-council