[tei-council] classy part

[Syd Bauman]

> This all sounds very reasonable to me.

Check. Probably need a better name than 'att.partial', though, no? 


> This sound plausible, but I'm a bit worried about the number of
> @type attributes which remain not inherited -- quite a lot last
> time I looked.

We have lots of uninherited type= attributes because we want to
specify the value list for lots of them. We need a mechanism for
specifying the value list for an inherited attribute.


> e need to work out a rationale for deciding when this is right and
> when it isn't rather than make piecemeal changes, I suggest. And
> your footnote gives one reason why this particular piece maybe
> shouldn't be changed.

Maybe, but (as I've complained about before) we already have a
proliferation of pointless subtype= attributes.


> > Someone would need to come up with good generic or exhaustive wording
> > for the <desc> of part= and its values.
> For "[ block | line | division | segment ] " read "element carrying
> this attribute" ?

Probably works for any given occurrence of the specialized word, but
eventually is going to start sounding like pronoun-less poetry:

     Little Bo Peep has lost Little Bo Peep's sheep,
     and doesn't know where to find Little Bo Peep's sheep.
     Leave Little Bo Peep's sheep alone, 
     and Little Bo Peep's sheep will come home,
     dragging Little Bo Peep's sheep's tails behind Little Bo Peep's sheep.

:-)


> Yes. So on what grounds are you now proposing to revise this
> principle? I'm happy to revise it, but I'd like to know what the
> rationale is!

We've revised this principle all over the place, haven't we? I
thought our general principle was to inherit the type= wherever
possible, despite subtype=. I am not sure what the rationale is in
general (remember, I was pretty strongly against this "everything
that has a type= gets a subtype=" approach), but in this particular
case it's just to make TEI more consistent, even if (IMHO) a bit
silly.