RE: possible issue with LEIRI definition in draft-duerst-iri-bis-02.txt

Hello Paul,

At 00:44 08/07/31, Grosso, Paul wrote:
>
>Martin,
>
>The XML Core WG does believe that all of our specs
>that allow what we are calling LEIRIs actually allow
>Legacy Extended IRI *references*.  

Okay. I have added *references* in a few more places,
and added a sentence that should make clear that the
general provisions for LEIRIs also apply to LEIRI
references. I have published this as draft-duerst-iri-bis-04.txt.
Please check the change log section, too.

Any suggestions for further tweaks and changes are welcome,
but please note that I'm on vacation for two weeks from
tomorrow.

With kind regards,    Martin.

>I suppose that means you could define the term LEIRI
>to mean Legacy Extended IRI *reference* in section 7
>of IRI-bis, but I would think that would be confusing.
>And I suppose we may find a spec out there that 
>requires a Legacy Extended IRI rather than a
>Legacy Extended IRI reference.
>
>So I would tend to have IRI-bis section 7 define both
>LEIRI and LEIRI reference (as I believe you are saying
>you've done in your latest internal draft), and then
>the XML Core specs that are awaiting IRI-bis can use
>the term "LEIRI reference".
>
>thanks,
>
>paul
>
>> -----Original Message-----
>> From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] 
>> Sent: Tuesday, 2008 July 29 20:26
>> To: Grosso, Paul; Addison Phillips
>> Cc: public-xml-core-wg@w3.org; public-i18n-core@w3.org; 
>> public-iri@w3.org
>> Subject: Re: possible issue with LEIRI definition in 
>> draft-duerst-iri-bis-02.txt
>> 
>> Hello Paul, others,
>> 
>> At 02:31 08/03/05, Grosso, Paul wrote:
>> >
>> >I was just rereading the LEIRI section of
>> >http://www.ietf.org/internet-drafts/draft-duerst-iri-bis-02.txt
>> >where it says:
>> >
>> > The syntax of Legacy Extended IRIs is the same as that
>> > for IRIs, except that ucschar is redefined....
>> >
>> >In section "2.2. ABNF for IRI References and IRIs", it
>> >has a production for IRI (that has a required scheme)
>> >and another for IRI-reference.
>> >
>> >One could read section 7 to say that a LEIRI must match
>> >the production for IRI which would mean there could be
>> >no such thing as a relative LEIRI.  I'm quite sure we
>> >don't want this.
>> 
>> True indeed.
>> 
>> >I think section 7 needs to say:
>> >
>> > The syntax of Legacy Extended IRIs is the same as that
>> > for IRI-reference, except that ucschar is redefined....
>> 
>> That's unfortunately not good enough. There should
>> be a clear correspondence, as follows:
>> 
>> LEIRI               ->   IRI
>> 
>> LEIRI reference     ->   IRI reference
>> 
>> I have fixed this by adding the following short paragraph
>> after "The iprivate production becomes redundant.".
>> 
>> >>>>
>> Likewise, the syntax for Legacy Extended IRI references
>> (LEIRI references) is the same as that for IRI references
>> with the above redefinition of ucschar applied.
>> >>>>
>> 
>> Please tell me whether this is appropriate for you.
>> It may be that some of your specs currently use the
>> term LEIRI when they indeed mean an LEIRI reference,
>> in which case they should be adjusted.
>> 
>> It may be that indeed all or most of your specs want
>> to reference LEIRIs. In that case (especially if it's
>> all), it might be approriate to rewrite section 7 of
>> the current draft to concentrate on LEIRI references
>> (maybe as far as changing the title to Legacy Extended
>> IRI References). In particular if it's all your specs,
>> the rewrite should be straightforward. Please advise.
>> 
>> In general, both the URI spec and the IRI spec are careful
>> to use the correct terms where only one of them applies,
>> but they do not necessarily always use both terms if
>> both apply; doing so would make the spec unreadable.
>> This is usually covered by some general clause saying
>> that certain things also apply to references,...
>> 
>> Regards,    Martin.
>> 
>> 
>> 
>> >since the production for IRI-reference is:
>> >
>> >  IRI-reference = IRI / irelative-ref
>> >
>> >making IRI-reference the most inclusive one.
>> >
>> >paul
>> 
>> 
>> #-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
>> #-#-#  http://www.sw.it.aoyama.ac.jp       
>> mailto:duerst@it.aoyama.ac.jp     
>> 
>> 


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp

Received on Monday, 4 August 2008 05:44:12 UTC