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*.  

That was my guess too, but I didn't want to imply anything.

>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.

I very much agree.

>And I suppose we may find a spec out there that 
>requires a Legacy Extended IRI rather than a
>Legacy Extended IRI reference.

Yes indeed.

>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".

Okay. I have indeed put in the term LEIRI reference,
but given that this is the main term you are after,
I'm planning to tweak the balance a bit more in favor
of it (I'd gess currently it's LEIRI 20 vs. LEIRI
reference 1).

I hope to get this done over the weekend, and plan to
make this -04 to give you a chance to check.

Regards,    Martin.

>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 Thursday, 31 July 2008 07:11:51 UTC