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

[Sebastian Rahtz]

On 6 Jan 2013, at 19:08, Lou Burnard <lou.burnard at retired.ox.ac.uk> wrote:

> 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

why do we still have that restriction, I wonder? it used to be, I think,
'cos we had that restriction on valItem/@ident, but that is no longer the case.
what would go wrong if we said data.enumerated used data.word instead
of data.name?

apologies if we've had this discussion in the past and I have forgot.
> 
> 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.

you can have data.key, pointing to data.word, as a specialization;
just as data.enumerated points at data.name now.

so we might do the following:

 - change @ed to be data.key or data.enumerated (I vote for key myself, but am not wedded to it)
 - zap data.code
 - change data.enumerated to point to data.word
 - add @edRef, using data.pointer
--
Sebastian Rahtz      
http://www.justgiving.com/SebastianRahtz
Director (Research Support) of Academic IT Services 
University of Oxford IT Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431