[tei-council] @key to be deprecated?

Mon Sep 19 11:12:39 EDT 2011

Hi James,

On 11-09-19 06:52 AM, 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.

Isn't foo:blort:1234 just magic too? If I've understood the proposal 
correctly, foo: and blort: don't resolve to anything meaningful; isn't 
foo:blort:1234 just a magic key that happens to have colons in it?

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

Backward-compatibility is the obvious one.

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

In that case, we're going to have an escalating tension between the 
Birnbaum doctrine and the need to clean up problems in P5 (like this 
one, perhaps, if you see it as a problem).

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

You actually caught me doing that (inadvertently) in an early version of 
the Image Markup Tool, IIRC. And I agree that's completely wrong when 
using @ref; but I would argue that's why @key is helpful. When you're 
still working out the structure of your repository and the relative 
locations of files and subcollections, not having to be precise about 
the path to a particular @xml:id is very handy. And if you get rid of 
@key, people are just going to use @n for the same job, I bet.

Cheers,
Martin

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

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)