[tei-council] @key to be deprecated?

Tue Sep 20 12:22:22 EDT 2011

The lengthy 2007 discussion beginning here:

<http://lists.village.virginia.edu/pipermail/tei-council/2007/007519.html>

seems to be all over the map. There are arguments in favour of keeping 
both @cRef and @key (even Sebastian arguing in favour of @cRef at one 
point).

But I can't find Sebastian's argument that @ref and @target are usefully 
distinct. Anyone know where it is?

Cheers,
Martin

On 11-09-20 08:30 AM, Lou Burnard wrote:
> I've *never* understood why we still have @cRef -- it was an early
> attempt to define a private Xpath syntax. Ground breaking for the time,
> but since superceded big time. However, Birnbaum Doctrine decrees that
> we can't just nix it.
>
> We did earlier on have a long discussion about the difference between
> @ref and @target, ifirc, in which Sebastian persuaded me (at least) that
> we needed both and they were usefully distinct.
>
>
> On 20/09/11 16:27, Martin Holmes wrote:
>> That brings @cRef and @target into the discussion too. I guess we really
>> do need to address all of these in one proposal.
>>
>> As far as I can see, the same arguments apply to @cRef as to @key, so
>> presumably it would also be on the table for deprecation; and I'm now
>> not sure whether @target and @ref are sufficiently distinct in purpose
>> and usage for both to be useful in the long run. Thorts?
>>
>> You're right that we should go to TEI-L once we have a clear ticket for
>> discussion.
>>
>> Cheers,
>> Martin
>>
>> On 11-09-20 08:19 AM, David Sewell wrote:
>>> Should the issue of deprecating @key be submitted for discussion to
>>> TEI-L before any final decision is made? So far as I can see, this has
>>> been mentioned only once on TEI-L in posts by Gabby and James, see
>>> http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind1102&L=TEI-L&P=R297
>>>
>>> David
>>>
>>> On Tue, 20 Sep 2011, Martin Holmes wrote:
>>>
>>>> OK, I'm becoming convinced on this. It looks like we need a ticket in
>>>> SF, along the lines of:
>>>>
>>>> 1. @key will be deprecated. (Still not exactly clear on that process.)
>>>>
>>>> 2. @ref will be added wherever @key is currently allowed, but @ref is not.
>>>>
>>>> 3. All examples showing @key will be changed to show @ref, and magic
>>>> tokens without colons will be replaced with magic tokens that have colons.
>>>>
>>>> 4. The documentation for @ref will be expanded to include an explanation
>>>> and examples of URIs which are not URLs (by which I presume we mean:
>>>> URIs which do not resolve to anything that can be located on the network).
>>>>
>>>> Have I missed anything? Does this replace or subsume any existing tickets?
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>> On 11-09-19 08:49 AM, James Cummings wrote:
>>>>> On 19/09/11 16:12, Martin Holmes wrote:
>>>>>> Hi James,
>>>>>
>>>>> Hi Martin,
>>>>>
>>>>>>> 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?
>>>>>
>>>>> Yes, that is what I meant be 'just as much magic'. They are both
>>>>> magic. However, the URN-style magic key is a faceted one. (I know
>>>>> you could just make your @key value do this as well.)
>>>>>
>>>>>> Backward-compatibility is the obvious one.
>>>>>
>>>>> Yes, agreed.
>>>>>
>>>>>> 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).
>>>>>
>>>>> Perhaps, but the Birnbaum Doctrine doesn't say that we're not
>>>>> allow to break backwards compatibility, just that we should have
>>>>> a deprecation structure to do so.
>>>>>
>>>>>> You actually caught me doing that (inadvertently) in an early version of
>>>>>> the Image Markup Tool, IIRC.
>>>>>
>>>>> Oh yes, I remember that, naughty Martin. :-P (He says quickly
>>>>> hiding any of his code where he certainly sins in greater orders
>>>>> of magnitude.)
>>>>>
>>>>>> 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.
>>>>>
>>>>> Surely since you *can* do this ref="foo" then people will just do
>>>>> that while they are still working out their repository structure
>>>>> or system of magic keys?
>>>>>
>>>>>> And if you get rid of
>>>>>> @key, people are just going to use @n for the same job, I bet.
>>>>>
>>>>> What people abuse @n for something that is not a potentially
>>>>> non-unique number or other label, but instead some magic token to
>>>>> identify specific classes of elements?  Never... no one would
>>>>> ever do that!  I mean that would be like using @rend to refer to
>>>>> _output_ rendition not source rendition. *grin*  Erm, yeah, ok, I
>>>>> see your point. People would certainly do that, yes.
>>>>>
>>>>> I still think using a URN-like URI on @ref is better because it
>>>>> forces you to consider _some_ form of classification or
>>>>> documentation principle. But yours are all good arguments for
>>>>> maintaining @key.
>>>>>
>>>>> -James
>>>>>
>>>>
>>>>
>>>
>>
>
> _______________________________________________
> 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)