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

[Martin Holmes]

Fair enough. I see so much abuse of data.pointer attributes that I guess 
I've become immune to it; I've lost count of the number of times I've 
said "you do know that this points to a file called xxxx which doesn't 
exist, don't you?"

But the precedent of @lemma and @lemmaRef is a good one; that inclines 
me towards solution c), adding @edRef, with a plan to deprecate @ed in 
the long term.

Cheers,
Martin

On 13-01-05 02:00 PM, 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
>>>>
>>>>
>>>
>