[tei-council] another High Noon proposal

[Lou Burnard]

On 11/01/13 08:44, Sebastian Rahtz wrote:
> yes. its always been true that a customization can say it does not 
> want one of the attribute class members. now we support this form of 
> modification purely within the Guidelines themselves, before the 
> customization comes anywhere near it. <abbr> is a member of att.typed, 
> but rejects @subtype. So your customization cannot put that @subtype back 

Now I am really worried. I am a user of the Guidelines. I see that 
<abbr> is a member of att.typed 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?

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?

 >what happened last summer was the _implementation_ of this facility. 
it didn't exist before last July at all. I used it on <abbr> and <title> 
to prove it worked (and changed the <desc> as >well, I think) and 
assumed this was what we had intended all along. this week I used it 
again, to make <binaryObject> a member of att.media, but remove the @url 
attribute from the >inherited set. This is what Lou noticed, and 
realized that it upset him. So nothing has changed since last year, just 
that the uses of the facillty start to cause raised eyebrows. Your task 
is >decide whether you think use of <attDef mode="delete" ..> should be 
banned in the P5 source.

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!

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 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 vote for an explicit ban on <attDef 
mode="delete" ..> in the P5 source.