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

[Lou Burnard]

On 06/01/13 15:56, Sebastian Rahtz wrote:
> Syd's useful analysis explains, I think, what happened. We set up data.code with the
> intention of it being a special case of linking to a set of known values, but then
> forgot the plan and made it a pointer instead.

I for one did not forget that data.code was meant not to be a pointer, 
but I seem to remember being over-ruled!

>
>>
>> So I'm thinking (reiterating some of
>> this thread) we have three choices:
>>
>> * change @ed to data.pointer,..
>> * change @ed to data.enumerated
>> * change @ed to data.enumerated, and provide @edRef as a
>>   data.pointer.
>
>
> everyone who has spoken seems in favour of the last of these - any objections?

data.enumerated is (as we agreed on a previous thread) constrained to be 
an XML name so ed="1666" would actually be illegal.


> (though I think I'd say data.key not data.enumerated, as that seems to fit
> the "everyone knows" case of "1661 edition" better)

Yes, data.key probably has the right semantics here, although it doesn't 
actually exist in the TEI any more. I seem to remember some inconclusive 
argument about what the distinction between data.key and data.code 
should be, but the only upshot seems to have been the abolition of 
data.key and mass deployment of anyURI even in rather dubious contexts.

I think the answer is to change the datatype of data.code from anyURI 
(which is silly) to data.text (which is painful, since it permits 
blanks, but is consistent with what we currently do with @key)

Or (better) to reinvent data.key as something intermediate between 
data.name and data.text


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