[tei-council] Question about attribute definitions and descriptions

[Martin Holmes]

I've added datatypes to all the non-controversial ones. The one 
outstanding issue is moduleSpec, as Sebastian says:

> we have one instance of moduleSpec/@type, viz
>
> <moduleSpec xml:id="DSTTEI2" ident="tei" type="core">
>
> I suggest removing the valDesc and simply make moduleSpec a member of att. typed.
> I agree that it looks like unfinished work, and in its present state is confusing

I'm going to raise a ticket for that, because it's potentially a bit thorny.

Can't tell at the moment whether my changes have broken anything, 
because builds are currently broken anyway -- Sebastian, shall we revert 
your changes to Makefile to allow builds to go ahead, while we figure 
out a different solution to the p5subset.xml problem?

Cheers,
Martin

On 12-02-09 05:30 AM, Martin Holmes wrote:
> 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
>>
>>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)