[tei-council] @key to be deprecated?

Mon Sep 19 10:02:03 EDT 2011

I haven't gotten around to replying to this yet, but I think I'd agree 
with the first paragraph of James's formulation below (without even 
needing to play Devil's advocate).

I wasn't part of the original conversation about @key, but I admit when 
I first heard of it, and the justification of it which I recall coming 
from Lou, I thought it was a great idea. Encouraging the use of uris 
(even locally defined *and documented*) over processor-specific keywords 
would be very cool.

(And if anyone can be discouraged from using @ref and @key on the same 
element to point to different kinds of reference on the same item, that 
can only be for the good too. ::blinks:: )

But as I think we're hearing, a long runway and reëducation to this 
deprecation is probably needed.

G

On 2011-09-19 14:52, James Cummings wrote:
> On 19/09/11 13:47, Martin Holmes wrote:
>> I would argue strongly against dropping @key. Would anyone argue in favour?
>>
>> I think if we do discuss it, it should be from the point of view of
>> settling on a more detailed set of recommendations on how to use it
>> (along the lines of the methods proposed by Sebastian and Kevin).
>
> I'll play devil's advocate on this. I think using URIs (in the
> form of URNs), even just locally constructed ones like
> foo:blort:1234 is a much better system than just bare keys which
> are just as much magic. The only reasons I can think of for using
> data.key for this kind of thing is ease of input. (Which then I
> would post-process to a more specific URN or a URL depending on
> use-case). What are some good reasons maintaining @key?
>
> However, there are some caveats to that... @key has been around
> for quite some time and I know is being used significantly in the
> wild. Either a long period of warning before deprecation is
> needed, or it would be something for P6. (Which, btw, I still
> argue we have committed in TCW09 to *not* moving to except in the
> emergence of new technologies (e.g. SGML to XML) or a major new
> architectural/infrastructural change.)
>
> I would also agree with Martin that more detailed recommendations
> are needed. One of the most frequent errors I notice are people
> doing things like: ref="foo" where there is not a file 'foo' (or
> even foo.xml), but where 'foo' is an xml:id not in their current
> document but in a document relating to the kind of element it is
> on.  So<persName ref="foo">Mr Foo</persName>  gets changed in
> their processing to be<persName
> ref="files/over/there/people.xml#foo">Mr Foo</persName>  (or more
> likely the processing just understands that and creates the
> output using the information).  The more we can dissuade people
> from this, the better. And better/more documentation of it is
> probably the first step.
>
> -James
>
>>
>> Cheers,
>> Martin
>>
>> On 11-09-18 11:45 PM, Laurent Romary wrote:
>>> Now that I read the ticket again, it looks like a strong pre-P6 item to be put on the November meeting agenda: "magic token" or shall we drop @key?
>>>
>>>
>>> Le 16 sept. 2011 à 15:30, Kevin Hawkins a écrit :
>>>
>>>> I'm not sure what made Martin recall this discussion about deprecating
>>>> @key, but this is exactly what I was brought up in another thread
>>>> yesterday.  See:
>>>>
>>>> http://www.tei-c.org/Activities/Council/Meetings/tcm45.xml
>>>>
>>>> for which the discussion about @key seems to reference this ticket:
>>>>
>>>> https://sourceforge.net/tracker/?func=detail&aid=2919640&group_id=106328&atid=644065
>>>>
>>>> --Kevin
>>>>
>>>> On 9/16/2011 2:08 AM, Laurent Romary wrote:
>>>>> HI Martin,
>>>>> I don't remember such a thing, and @key is indeed needed in many cases where there is no reference description for a given entity.
>>>>> Cheers,
>>>>> Laurent
>>>>>
>>>>> Le 15 sept. 2011 à 23:34, Martin Holmes a écrit :
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I seem to remember some discussion about deprecating @key, or changing
>>>>>> it to a URI, but I can't find any mention of it in the archives or on
>>>>>> SF. Does anyone remember anything about this? I find I really need it
>>>>>> for something, in a context where I can't use a URI, so I want to make
>>>>>> sure it's going to continue to be available.
>>>>>>
>>>>>> Cheers,
>>>>>> Martin
>>>>>> --
>>>>>> Martin Holmes
>>>>>> University of Victoria Humanities Computing and Media Centre
>>>>>> (mholmes at uvic.ca)
>>>>>> _______________________________________________
>>>>>> tei-council mailing list
>>>>>> tei-council at lists.village.Virginia.EDU
>>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>>>>
>>>>>> PLEASE NOTE: postings to this list are publicly archived
>>>>>
>>>>> Laurent Romary
>>>>> INRIA&     HUB-IDSL
>>>>> laurent.romary at inria.fr
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> tei-council mailing list
>>>>> tei-council at lists.village.Virginia.EDU
>>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>>>
>>>>> PLEASE NOTE: postings to this list are publicly archived
>>>> _______________________________________________
>>>> tei-council mailing list
>>>> tei-council at lists.village.Virginia.EDU
>>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>>
>>>> PLEASE NOTE: postings to this list are publicly archived
>>>
>>> Laurent Romary
>>> INRIA&    HUB-IDSL
>>> laurent.romary at inria.fr
>>>
>>>
>>>
>>> _______________________________________________
>>> tei-council mailing list
>>> tei-council at lists.village.Virginia.EDU
>>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>>
>>> PLEASE NOTE: postings to this list are publicly archived
>> _______________________________________________
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived
>
>

-- 
Dr Gabriel BODARD
(Research Associate 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/