[tei-council] att.sourced (<lb ed="1674">) contradiction

[Lou Burnard]

Not sure about that. Some TEI datatypes provide both information about 
both what sort of value this is and also how it should be used. 
data.enumerated, for example says "the value should (actually or 
potentially) come from a fixed list of possible values". It also says 
"the value looks like an XML name". If we found a way of implementing 
enumerations which didn't need the additional constraint of being a 
name, then we'd change the mapping of data.enumerated

Simly, I think I'd prefer to retain (or reinsert) data.key for its 
ability to say "this is an identifier of some non-pointerly kind that 
everyone recognizes" distinct from data.word -- the latter (analogously 
to data.name) provides only information that this thing has certain 
syntactic constraints.


   On 06/01/13 17:52, Syd Bauman wrote:
> The advantage of data.word is that a value could start with a digit
> (like "1674"). The advantage of data.enumerated is that means the TEI
> is saying (appropriately, I think) "you should document your set of
> values in your ODD". Personally, I think the latter is more
> important, but it also would break backwards compatibility, so I'm
> thinking we should leave the official datatype as data.word, perhaps
> with some sort of prose recommendation for defining a constrained
> value list via <valList> in your ODD.
>
>
>> since data.code is not used anywhere except in att.sourced, and
>> data.key is not used at all, we can drop both of them in favour of
>> data.word