Re: redefining a namespace prefix and Base IRI definition

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.

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