[tei-council] Question about attribute definitions and descriptions

[James Cummings]

On 08/02/12 19:26, Martin Holmes wrote:
> 1. Should all attributes with a closed valList be specified as
> data.enumerated? "data.enumerated defines the range of attribute values
> expressed as a single XML name taken from a list of documented
> possibilities." This (to my reading) doesn't specify whether the list of
> possibilities is closed or open, so I think it can/should apply to
> closed valLists as well. If it doesn't, we need another datatype that
> does, because I think an attribute without a datatype is not a good thing.

IMHO, all attributes, where they aren't some other datatype for 
some reason, but consist of a documented list of XML names should 
be data.enumerated.  I.e. if they are something else, fine.  If 
they aren't a documented list, then they are data.word or 
something, for the datatype it doesn't matter if the list is open 
or closed.  Having a datatype is definitely better than not 
having one.

> 2. rendition/@scope has no @type on its valList. It should have one, I
> think, and it looks like it ought to be closed, because the values are
> taken from CSS pseudo-classes.

Currently the reference page says 'Sample values include' because 
it isn't closed.  If we do make this closed, it would have to 
contain all the CSS pseudo-elements from any version of the CSS 
spec.  I *think* this is limited to:active, after, before, 
first-child, first-letter, first-line, focus, hover, lang(en), 
link, and visited. However, I think we'd need a volunteer to go 
back to the CSS specs and make sure I'm not missing any.  The 
thing to decide, I guess, is whether it is an error to supply a 
value here which is not one of those?

> 3. moduleSpec/@type has only been partially defined. the valDesc
> suggests it should be a closed valList, but there is no valList. It
> looks as though work on this was interrupted half-way through.

I'm not sure. Although the TEI may have need for a closed set of 
values here, remember that ODD can be used entirely separate from 
the TEI.  Is there a consistent set of moduleSpec type 
categorisations which don't limit other uses of it?  As far as I 
can tell the TEI itself, in the production of the Guidelines or 
our exemplar ODDs, do not use @type on moduleSpec.  (Can someone 
correct me on this?)

<gap reason="snipped"><desc>list of attributes without dataypes 
snipped</desc></gap>

-James


-- 
Dr James Cummings, InfoDev,
Computing Services, University of Oxford