W3C home > Mailing lists > Public > public-iri@w3.org > July 2008

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

From: Grosso, Paul <pgrosso@ptc.com>
Date: Wed, 30 Jul 2008 11:44:24 -0400
Message-ID: <CF83BAA719FD2C439D25CBB1C9D1D3020C3BA62A@HQ-MAIL4.ptcnet.ptc.com>
To: "Martin Duerst" <duerst@it.aoyama.ac.jp>, "Addison Phillips" <addison@yahoo-inc.com>
Cc: <public-xml-core-wg@w3.org>, <public-i18n-core@w3.org>, <public-iri@w3.org>


The XML Core WG does believe that all of our specs
that allow what we are calling LEIRIs actually allow
Legacy Extended IRI *references*.  

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



> -----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     
Received on Wednesday, 30 July 2008 15:45:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:39:39 UTC