[tei-council] @key to be deprecated?

[Martin Holmes]

I think we're talking about trying to arrive at a much simpler system in 
the very long run (hence deprecation); once again, here, we have 
multiple ways of doing the same thing, some of which we're proposing to 
recommend (URIs in @ref) and the other of which we're going to continue 
to allow (magic tokens in @key). One of the most common complaints we 
hear both from experts and from new users is that TEI has too many ways 
of doing the same thing, so where one method is clearly superior to the 
other, we should surely plan to move towards it.

Cheers,
Martin

On 11-09-20 08:24 AM, Lou Burnard wrote:
> I'm not sure that I agree with Martin's analysis.
>
> a) Are there any places where @key is permitted but not @ref? if there
> are, then I agree that @ref should be added as an alternative
>
> b) Changing *all* examples using @key to examples using @ref seems like
> an over reaction to me though I agree that we need to increase the
> number of examples using @ref=my:uri:notation
>
> I had interpreted the sense of the preceding discussion to be that we
> understood why people might want to supply a privately magic token as
> the value for @key but that they needed to be reminded that an
> alternative slightly less magical option would be to use @ref with the
> proposed URI syntax.
>
>
>
>
> On 20/09/11 16:19, 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)