[tei-council] another High Noon proposal
Lou Burnard
lou.burnard at retired.ox.ac.uk
Fri Jan 11 08:21:49 EST 2013
On 11/01/13 12:59, Sebastian Rahtz wrote:
> 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
Interestingly, this is true for <abbr>, but not for <binaryObject>. The
HTML display for the former looks just the same in the most recent build
as it ever has i.e. it looks as if @type is locally defined. For
binaryObject, however, there is no documentation of or reference to the
att.media class attributes it now has at all, except in the declaration
for the element. That surely is a bug?
> 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
My point though is that adding it to the class (and thus gaining
@subtype) is probably an improvement to the schema
>> 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=644065ut th
For the record, this ticket discusses *only* modification -- not deletion
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
My vote is for 1, and for <abbr> and <title> gaining subtitle.
More information about the tei-council
mailing list