[edits in 1.501] redefining a namespace prefix and Base IRI definition

I committed these changes in 1.501 .
Comments and nitpicking 117 lines down.

On Mon, Sep 26, 2005 at 10:32:56AM -0400, Eric Prud'hommeaux wrote:
> On Mon, Sep 26, 2005 at 09:38:49AM +0100, Seaborne, Andy wrote:
> > 
> > 
> > 
> > Eric Prud'hommeaux wrote:
> > >We have two shorthand syntaxes for building URIs: qnames and relative
> > >URIs. These two are intertwined in rw23:
> > >[[
> > >[A]
> > >SPARQL provides an abbreviation mechanism for IRIs. Prefixes can be
> > >defined and a QName-like syntax [NAMESPACE] provides shorter
> > >forms. Prefixes may be used anywhere after they are declared;
> > >redefining a prefix causes the new definition to be used from that
> > >point in the query syntax. The base IRI for the resolution of relative
> > >IRIs may be explicitly declared with the BASE keyword. This
> > >specification does not define the value of the base IRI for SPARQL
> > >queries with no BASE directive.
> > >
> > >[B]
> > >QNames are transformed into IRIs by appending the local name to the
> > >namespace name. Relative IRIs are combined with base IRIs as per
> > >Uniform Resource Identifier (URI): Generic Syntax [RFC3986] using only
> > >the basic algorithm in Section 5.2 . Neither Syntax-Based
> > >Normalization nor Scheme-Based Normalization (described in sections
> > >6.2.2 and 6.2.3 of RFC3986) is performed. Characters additionally
> > >allowed in IRI references are treated in the same way that unreserved
> > >characters are treated in URI references, per section 6.5 of
> > >Internationalized Resource Identifiers (IRIs) [RFC3987].
> > >]]
> > >
> > >Paragraph A defines how prefixes and Base IRIs are defined. B shows
> > >how they are used. This arrangement appears to be a bit confusing. In
> > >addition, Martin Dürst was confused by how they can be "used" before
> > >being redefined (a vestige of our former grammar where prefixes
> > >happened in multiple places in the grammar). The only way you could
> > >use them, progressively constructing a namespace in multiple passes:
> > >  PREFIX rq23: <http://www.w3.org/2001/sw/DataAccess/Overview.>
> > >  PREFIX rw23: rq23:html
> > >is prohibited by the grammar:
> > >  [4] PrefixDecl ::= 'PREFIX' QNAME_NS Q_IRI_REF
> > >
> > >We also have comments from Bjorne saying that we don't relate well to
> > >3986's text on resolving URIs relative to a base URI. This text is
> > >intended to address all this, and world hunger to boot:
> > >
> > >[[
> > >SPARQL provides a two abbreviation mechanisms for IRIs, prefixes and
> > >relative IRIs.
> > >
> > >The PREFIX keyword binds a prefix to a namespace IRI [NAMESPACE]. A
> > >prefix binding applies to any QNames in the query with that prefix; a
> > >prefix may be defined only once. A QName is mapped to an IRI by
> > >appending the local name to the namespace IRI corresponding to the
> > >prefix.
> > >
> > >Relative IRIs are combined with base IRIs as per Uniform Resource
> > >Identifier (URI): Generic Syntax [RFC3986] using only the basic
> > >algorithm in Section 5.2 .  Neither Syntax-Based Normalization nor
> > >Scheme-Based Normalization (described in sections 6.2.2 and 6.2.3 of
> > >RFC3986) is performed.  Characters additionally allowed in IRI
> > >references are treated in the same way that unreserved characters are
> > >treated in URI references, per section 6.5 of Internationalized
> > >Resource Identifiers (IRIs) [RFC3987].
> > >
> > >The BASE keyword defines the Base IRI used to resolve relative IRIs
> > >per RFC3986 section 5.1.1, "Base URI Embedded in Content".  Section
> > >5.1.2, "Base URI from the Encapsulating Entity" defines how the Base
> > >IRI may come from a an encapsulating document, such as a SOAP envelope
> > >with an xml:base directive, or a mime multipart document with a
> > >Content-Location header. The "Retrieval URI" identified in 5.1.3, Base
> > >"URI from the Retrieval URI", is the URL from which a particular SPARQL
> > >query was retrieved.
> > >]]
> > >
> > >
> > >ISSUES:
> > >
> > >- Do we want to alter the grammar to allow progressive declarations?
> > >I say "no".
> > 
> > +1 to "no"
> > 
> > The cases where it would be useful are rather few because the local part of 
> > an abbreviated qname can't start with "/" or "#".
> > 
> > 
> > Given this, I would also say the prefix IRI is resolved then the qname 
> > rules of concat(prefix, local part) applied.  (I can't think of case where 
> > it makes a difference because you can't, say split ".." across the prefix 
> > and the local part).  The grammar does not imply whether it's
> > 
> >   concat(resolve(prefix), local part)
> > 
> > or
> > 
> >   resolve(concat(prefix, local part))
> > 
> > 
> > I think this is fact covered by the text because "URI" in RFC 3986 means 
> > the whole thing and "absolute URI" as being without the fragment in
> > "4.3.  Absolute URI" but it might be worth making it clear.
> 
> I haven't done the arithmetic, but I assumed that the there was no way
> to squeeze any relevent characters into a NCNAME.
>   see http://www.w3.org/2001/sw/DataAccess/rq23/#rQName
> 
> 
> > > The PREFIX keyword binds a prefix to a namespace IRI [NAMESPACE].
> > 
> > The PREFIX keyword binds a prefix to a namespace IRI [NAMESPACE] after 
> > relative IRI resolution has been applied.
> 
> Good point. Will try to remember to include in text.

I opted against as I believe that doing namespace substitution and
then relative IRI resolution yields the same thing as relative IRI
resolution on namespaces:

given:
  BASE <http://example.org/dir1>
  PREFIX a: <dir2>
  ASK {a:b ?p ?o}

relative IRI resolution applied to <dir2>:
  a: := <http://example.org/dir2>
  a:b = <http://example.org/dir1b>

relative IRI resolution applied to substituted names:
  a: := <dir2>
  a:b = <dir2:b> which resolves to <http://example.org/dir1b>

I believe Andy disagrees with this (see log). I have attached the text
I would commit if folks prefer Andy's words (requires some re-ordering
of the paragraphs).

> > >- What does
> > >[[
> > >The use of relative IRI references, including same-document
> > >references, in namespace declarations is deprecated.
> > >
> > >Note:
> > >
> > >This deprecation of relative URI references was decided on by a W3C
> > >XML Plenary Ballot [Relative URI deprecation]. It also declares that
> > >"later specifications such as DOM, XPath, etc. will define no
> > >interpretation for them".
> > >]]
> > >mean in the namespaces spec [NSPACE]?
> > 
> > 
> > There would be an implication on SPARQL that apps shoudl not use relative 
> > IRIs in PREFIX.
> 
> Intentionally or not, the current grammar forces that upon us anyways:
>   [4] PrefixDecl ::= 'PREFIX' QNAME_NS Q_IRI_REF
>   [66] Q_IRI_REF ::= '<' ([^<>]-[#00-#20])* '>'
> http://www.w3.org/2001/sw/DataAccess/rq23/#rPrefixDecl
> 
> > 	Andy
> > 
> > >
> > >
> > >- 3986 talks about SPARQL inside SOAP. SPARQL Protocol should as well.
> > >
> > >
> > >- 3986 doesn't mention any recursion for resolving Base URIs for
> > >encapsulating entities.
> > >
> > >
> > >- SPARQL uses "IRI" and 3986 uses "UIR". I tried to quote
> > >strategically in order to show how the terms applied to each document.
> > >
> > >[NSPACE] http://www.w3.org/TR/xml-names11/#iri-use
> > 
> 



-- 
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +81.90.6533.3882

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.