[tei-council] @key to be deprecated: @loc involved too?
Laurent Romary
laurent.romary at inria.fr
Sat Sep 24 01:08:01 EDT 2011
Excellent. I know it's not an easy move, but I have the strong feeling that it is a very important one to improv the cohenrence of the guidelines.
Le 23 sept. 2011 à 17:31, Martin Holmes a écrit :
> I've now filed a bug ticket here:
>
> <http://purl.org/TEI/BUGS/3413346>
>
> Cheers,
> Martin
>
> On 11-09-22 11:50 PM, Laurent Romary wrote:
>> Especially when one of the two examples in the guidelines using the @loc attribute is actually pointing to an ID! see http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCSCWL
>> Add this to the ticket...
>>
>> Le 22 sept. 2011 à 18:36, Martin Holmes a écrit :
>>
>>> 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)
>>> _______________________________________________
>>> 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)
> _______________________________________________
> 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
More information about the tei-council
mailing list