[tei-council] @key to be deprecated: @loc involved too?

Thu Sep 22 12:36:23 EDT 2011

I see that @loc is also:

1–∞ occurrences of data.word

Should we be thinking about this changing to data.pointer too?

Cheers,
Martin

On 11-09-20 09:30 AM, Laurent Romary wrote:
> I follow Martin here (simpler system..;). Without any prejudice on the final outcome, I would urge him to file a ticket with the various elements he has mentioned in his last posts.
> Cheers,
> Laurent
>
> Le 20 sept. 2011 à 17:31, Martin Holmes a écrit :
>
>> 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)
>> _______________________________________________
>> 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
>
>
>
> .
>

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