TEIC
Expand specDesc to display valList
In a customization, people very often want to provide a more restrictive set of values for a given attribute: indeed, aside from element selection, this may be all they want to do. It's easy enough to add a <valList> into the ODD, but there's no way of getting the contents of that list included in the documentation, other than as a part of the reference documentation for the element (most of the rest of which looks incomprehensible or irrelevant). <specDesc> currently provides a nice way of extracting the <desc> for an element or attribute into the documentation: it would be nice to enhance it so as to do the same thing for a valList. I imagine this could be done by adding another attribute @vals to specify the attribute/s for which a valList is required. The format of the valList would presumably be the same as what is currently provided in the complete refdoc, but could be more usefully presented as part of the documentation for the ODD.
This sounds like a sensible idea to me. Presumably this would be whitespace-separated list of attributes for which the valList should be provided.
Questions:
Given: <specDesc key="foo" atts="type blort" vals="type blort wibble"/>
a) Is it an error if foo doesn't allow blort as an attribute?
b) Is it an error if I provide 'wibble' in the vals attribute but not in the atts?
c) Is it an error if the type attribute doesn't have a valList but appears in vals?
d) For these does this produce an error (or have a schematron rule that tests it?) Or do we allow it and processing produce an error? Or does it just silently drop those that are incorrect?
Part of me wonders if we should be expanding specDesc in a better way with children for each attribute turning on/off each attribute (so we could then do other things like specify whether that valList should be sorted or something.... but developing a whole new structure is probably overkill.
A) Is it an error if foo doesn't allow blort as an attribute?
Yes. Just like if @key value isn't a defined identifier
b) Is it an error if I provide 'wibble' in the vals attribute but not in the atts?
No. They do different things. On @atts you get the description. On @vals you get the valList. You might want either or both.
c) Is it an error if the type attribute doesn't have a valList but appears in vals?
Yes. Same as (a).
d) For these does this produce an error (or have a schematron rule that tests it?) Or do we allow it and processing produce an error? Or does it just silently drop those that are incorrect?
Say what?
...developing a whole new structure is probably overkill.
Yes indeed. Let's not do that.