[tei-council] Question about attribute definitions and descriptions

[Martin Holmes]

On 12-02-09 02:58 AM, James Cummings wrote:
> 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.

In that case, I'll go through them all and make them data.enumerated, 
unless anyone raises an objection in the next few hours.

>> 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?

Given the ref page text, I guess I was wrong; it should be open. CSS 
pseudo elements are likely to proliferate, so it would be potentially 
obstructive to close the list.

>> 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?)

I take the point, but it seems unintuitive to specify that the list is 
closed, and yet not be able or willing to provide the values. Surely if 
someone else can take the ODD spec and do something different with it, 
and they need to use their own values, then the list is actually open?

Cheers,
Martin

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