[tei-council] specDesc spec vs. reality

[Lou Burnard]

There are two different issues here.

a) should the attributes to be displayed for a <specDesc> be only those 
specified by @atts, or all those available?

b) should inherited attribuites be treated differently from 
locally-defined ones? i.e. can @atts request display of an inherited 
attribute?

I agree that removing the <remarks> concerning (a) is easy and probably 
advisable.

Regarding (b) I don't think requesting an inherited attribute should be 
regarded as an error. We don't make that distinction elsewhere (e.g. I 
can modify an inherited attribute in a elementSpec) and it is certainly 
not the way I remember things being done before.

I have an open mind on displaying valLists: how would that be switched 
on or off?



  On 08/12/13 22:34, Sebastian Rahtz wrote:
> My recollection of this feature is that it was only ever intended to deal with
> attributes defined locally; but if it was to be extended to cover class attributes too
> I’d not protest.  What would bother me would be if the default was to show
> all attributes from any source, as that would be so verbose as to be off-putting.
>
>> Similarly, the <remarks> on the element itself say hopefully
>>
>> "The description is usually displayed as a label and an item, with any
>> list of values defined
>> for the attribute as an embedded glossary list,"
>>
>> which is not currently the case: no list of values appears for
>> attributes specified on @atts, nor am I sure how you'd get one. (They
>> appear in the reference doc if a <valList> is supplied, but not sfaik
>> otherwise)
> I am not sure I’d have expected to see that valList in the summary anyway,
> but it would certainly be possible to implement it if needed.
>
> the easiest thing to do would be to remove the <remarks>, I must say :-}
> --
> Sebastian Rahtz
> Director (Research) of Academic IT
> University of Oxford IT Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>