[tei-council] @key to be deprecated?

[Martin Holmes]

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
>

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