[tei-council] Question about attribute definitions and descriptions

Martin Holmes mholmes at uvic.ca
Wed Feb 8 14:26:28 EST 2012


 > In all the cases I looked at the attribute values were a closed
 > value list with very specific values.  Perhaps these should be
 > made data.enumerated with a closed value list?

You're mostly right, but see the list below for one or two exceptions 
(marked with arrows). Numbers refer to 
<http://web.uvic.ca/lancenrd/martin/tei/valdescs.htm>. This raises some 
questions:

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.

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.

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.

===========ATTRIBUTES WITH NO DATATYPE======================

63   @dim       <space>              valList (closed)

74   @eol       <hyphenation>        valList (closed)

75   @evaluate  att.pointing         valList (closed)

86   @feature   <shift>              valList (closed)

92   @form      <quotation> [no valDesc or valList; deprecated]

102   @full     att.personal         valList (closed)

143   @level    <title>              valList (closed)

148   @location <variantEncoding>    valList (closed)

165-  @method   <correction>,        valList (closed)
  167            <normalization>,
                 <variantEncoding>

172-  @mode     <channel>,           valList (closed)
  177            <alt>,
                 <altGrp>,
                 <classes>,
                 <memberOf>,
                 att.combinable

207   @ord      <tree> 	             valList (closed)

213-  @org      att.divLike,         valList (closed)
  216            <vColl>,
                 <vMerge>,
                 <attList>

225-  @part     att.divLike,         valList (closed)
  228            att.segLike,
                 <l>,
                 <ab>

275   @sample   att.divLike          valList (closed)

278   @scheme   <rendition>          valList (closed)

288   @scheme   <tag>                valList (open) <----------
	
289   @scheme   <constraintSpec>     valList (closed)

291   @scope    att.handFeatures     valList (closed)

292   @scope    <rendition>          valList ()     <----------
	
293   @scope    <join>               valList (closed)

320-  @status   <availability>,      valList (closed)
  322            <correction>,
                 att.identified

353   @trans    <u>                  valList (closed)

376,  @type     <tech>,              valList (closed)
  377,           <recording>,
  394,           <constitution>,
  397,           <factuality>,
  398,           <interaction>
  408,           <tag>
  410,           <classSpec>
  411,           <macroSpec>
  412            <valList>

409   @type     <moduleSpec>         valDesc: A closed <----------
                                      set of keywords
                                      yet to be defined

426   @usage    <attDef>             valList (closed)

427   @valid    <egXML>              valList (closed)

467 @xml:space  att.global           valList (closed)

=====================================================

Cheers,
Martin

On 12-02-08 09:24 AM, James Cummings wrote:
> On 08/02/12 13:38, Martin Holmes wrote:
>> But now I'm wondering why<gi>   has a<datatype>   and<tag>   doesn't. In
>> fact, I'm wondering why so many attributes in the list lack a datatype.
>> They all seem to be attributes which should be data.enumerated.
>
> It does seem to happen with attributes which I would suspect
> should be data.enumerated.
>
>> Is this just a historical accident, or is there some reason or pattern
>> to it?
>
> In all the cases I looked at the attribute values were a closed
> value list with very specific values.  Perhaps these should be
> made data.enumerated with a closed value list?
>
> -James
>

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


More information about the tei-council mailing list