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

[Gabriel Bodard]

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

-- 
Dr Gabriel BODARD
Researcher in Digital Epigraphy

Department of Digital Humanities
King's College London
26-29 Drury Lane
London WC2B 5RL

Email: gabriel.bodard at kcl.ac.uk
Tel: +44 (0)20 7848 1388
Fax: +44 (0)20 7848 2980

http://www.digitalclassicist.org/
http://www.currentepigraphy.org/