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

[Lou Burnard]

I think most people who actually use @ed are quite comfortable with the 
idea of referring to an edition by means of a siglum such as "1815" or 
"Blenkinsop" without any particular need to point to an explanation of 
what that edition is. That's why it was originally defined in this way 
at any rate. Insisting that it become a pointer seems a bit harsh to me.
So my vote is for (a).

On 05/01/13 22:00, Gabriel Bodard wrote:
> But whether the file is technically valid or not is less of an issue as
> far as I'm concerned than whether a file uses the TEI correctly. There
> are all sorts of ways for a file to be valid but wrong (a pointer that
> has nothing at the target explaining what is in your markup). If @ed is
> defined to be a pointer to a description of the edition in question, and
> instead it is being treated as an arbitrary, conventional string, then
> even if the schema can't tell the difference that is a bigger kind of
> broken.
>
> The analogous case, for me, of an attribute that didn't get a strict
> pointer/valList datatype in P5, is @lemma, and there were have the
> parallel @lemmaRef for the case where someone wants to use it in the
> more strict way, so there's precedent for forking, I guess.
>
> G
>
> On 05/01/2013 21:45, Martin Holmes wrote:
>> If we do b), I don't think we'll actually break very much, will we? The
>> only case in which a currently-valid project would become invalid would
>> be where the identifiers happen to begin with a number. If that's only a
>> few cases, then it might be acceptable. Other cases where a cRef-style
>> identifier is used would be formally wrong (they would apparently point
>> to a file that didn't exist), but wouldn't show as invalid.
>>
>> Cheers,
>> Martin
>>
>> On 13-01-05 01:06 PM, Gabriel Bodard wrote:
>>> No I agree with you that a pointer makes sense, and of the three options
>>>
>>> a. define @ed to take text, like @cRef
>>> b. define @ed to be a pointer and take a uri
>>> c. fork @ed so we have ways to do both the above
>>>
>>> I like (a) the least. But I'm a bit torn between b. and c., simply
>>> because of all the people who have been misled by the text ("A string of
>>> characters or sigil used conventionally to identify the edition") and
>>> example in the guidelines, which I suspect is the majority. (I haven't
>>> used @ed very often, and certainly not very recently, but I don't recall
>>> what I put in it. Probably not a pointer.)
>>>
>>> Not feeling strongly enough about this to shout if there is a clear
>>> consensus for (b), however. :-)
>>>
>>> Gabby
>>>
>>> On 05/01/2013 14:00, Sebastian Rahtz wrote:
>>>>
>>>> On 5 Jan 2013, at 13:39, Gabriel Bodard <gabriel.bodard at kcl.ac.uk>
>>>>      wrote:
>>>>
>>>>> What about all the people who are now using @ed to contain a cRef like
>>>>> string that "conventionally expresses" the edition that has a linebreak
>>>>> at this point? (They should stop and start using a pointer instead of a
>>>>> cRef, I agree, but backwards compatibility?)
>>>>
>>>> people who are currently saying <lb ed="1665"/> are pointing
>>>> at a local file called "1665", though they realize it or not.
>>>>
>>>> the alternative is to change data.code to be simply text,
>>>> but the consider the question on TEI-L, where the questioner
>>>> asks where to define what @ed refers to.
>>>>
>>>> in fact, the _text_ about @ed really seems to suggest
>>>> use of data.key ("the range of attribute values expressing a coded value by means of an arbitrary
>>>> identifier, typically taken from a set of externally-defined possibilities")
>>>>
>>>> --
>>>> 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
>>>>
>>>>
>>>
>