[tei-council] specDesc spec vs. reality

[Lou Burnard]

According to the <remarks> on the attribute @atts of <specDesc>,

"The attribute names listed may include both attributes inherited from a 
class and those
  defined explicitly for the associated element."

"may" might mean anything, but in practice, with the current ODD 
processor, a reference to an inherited (rather than locally defined) 
attribute in a specDesc/atts generates an error, rather than a 
description of the attribute concerned. Can this be fixed? Should it be 
fixed?

The spec also says:

"If the <att>atts</att> attribute is not   supplied, then descriptions 
for all non-inherited attributes are listed, along with  references to 
any classes. If an empty string is supplied as the value for the 
<att>atts</att> attribute, then no description should be displayed"

This possibly contradicts what the <dec> says " supplies attribute names 
for which descriptions should *additionally* be obtained." (my emphasis) 
if  we understand "additionally" to mean "as well as describing the 
element". And it's not clear what "reference to any classes" means. 
Certainly it is not implemented in the current ODD processing model: a 
<specDesc> with no @atts does not provide a list of locally defined 
attributes.

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)

Should we change the spec to match our current practice, presumably by 
deleting the porky pies cited above?