[tei-council] another High Noon proposal

[Sebastian Rahtz]

On 11 Jan 2013, at 11:55, Lou Burnard <lou.burnard at retired.ox.ac.uk>
 wrote:
> 
> Now I am really worried. I am a user of the Guidelines. I see that 
> <abbr> is a member of att. typed

but you don't. you see it has a @type attribute 

> and, being used to the idea that it will 
> therefore have both @type and @subtype, I develop a fairly elaborate 
> typology for my abbreviations (Yes, my name is Matthew), which includes 
> subtyping. How do I get my @subtype back? If I *do* put it back, 
> presumably by adding it in my ODD, is my document no longer 
> TEI-conformant? Do I have to add my @subtype in its own namespace?
> 
these are moot issues

> Why did you decide to remove @subtype, btw? was there ever a feature 
> request to that effect, or were you just trying to find a way of testing 
> this new facility?

no. the old <abbr> had its own local copy of @type. I replicated the
effect by removing the local copy, adding it to att.typed, and then
zapping subtype. so the schema is the same as it was before

all as foreseen and discussed, I claim
> 

> The more I think about it, the more it upsets me! We have gone to quite 
> some effort in the past to ensure that elements inherit all and only the 
> attributes the need from classes, and the usual mechanism has been to 
> define additional sub or super classes.  Which works fine, though at the 
> expense of multiplying the number of classes. This seems to to provide a 
> different mechanism which has the side effect of nullifying the 
> definition of what an attribute class is!

well, we could make up att.subtyped, which is a member of att. typed
but adds a new attribute, to cope with <abbr> situation.

> 
> Going back to the @url example, by the way: if someone attempts to 
> restore @url to the element from which it's been deleted (binaryObject) 
> would that also be TEI-conformant? I'd say not, since <binaryObject>'s 
> only reason for existence is to provide inline the content which that 
> @url would indicate. Hence I'd say that restoring @url to it would break 
> the TEI semantic model. And hence, I argue, its presence in the 
> attribute class from which it would (if we hadn't stopped it) inherit 
> same is also semantically invalid.

i can see your argument. i think i regard att classes as less semantically
significant tho

> 
> I yield to no-one in my admiration for Sebastian's work in implementing 
> ideas we have only half formulated, but here I think implementation has 
> been a bit too previous.

I think that is a _bit_ unfair. the Council told me to make the ODD @mode
stuff work at source, so I did. I don't think it was previous….


for background, the SF ticket about this was https://sourceforge.net/tracker/?func=detail&aid=3415801&group_id=106328&atid=644065

> i vote for an explicit ban on <attDef 
> mode="delete" ..> in the P5 source.



I vote against that, on the grounds that a) I find it a felicitous side effect that we can zap @url
from binaryObject, the concept seems natural, and b) in general we should make ODD consistent
and try to avoid any special cases.  if you can do mods at source level, don't limit what those mods are.

of course, Lou's request can come in two flavours

   1. as an editing convention, lets not use attDef mode="delete" in TEI Guideline please
   2. lets make that ban part of the ODD spec and remove the implementation, and document the fact

if we go for 2., then I have to say I don't think its possible before the release, so we'd have to
put that off; if we go for 1, then we need to decide on whether <abbr> and <title>
should gain @subtype, or revert to local copies of the attribute

This is urgent. We are close to release, and there isn't a simple back-out 
which can be applied.
--
Sebastian Rahtz      
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431