Re: ACTION: ericP to add "don't normalize" to rq23 -- DONE?

[this message isn't really finished, but maybe it's better
shared in its present state...]

On Tue, 2005-08-16 at 09:59 -0400, Eric Prud'hommeaux wrote: 
> On Mon, Aug 15, 2005 at 06:12:47PM -0500, Dan Connolly wrote:
> > 8. BASE IRI resolution comment
> > 
> > ACTION: ericP to add "don't normalize" to rq23 (perhaps supplied in
> > 0096)
> [[
> 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. The resolution of relative
> IRIs in SPARQL queries with no BASE is not defined.
> ]]
> I defined QName resolution (not happy with it, but I think it's better
> than nothing). Text was stolen from RDF Syntax [SYNTAX].
> Somewhat counter to the advice of the comment [COMMENT], I used RFC
> 3986 to define relative IRI resolution.
> This brought up the question of resolution if no BASE is present. I
> use this feature in Algae a lot. BASE defaults to the URL of the
> query, which means that, be it in a file or a web page, FILE and GRAPH
> and the like can get to relative documents. Defining this would get
> well into execution environment, prohibiting it would prohibit a lot
> of convenient use cases, so I went with don't ask/don't tell.

That's one coherent approach, but I think it's messier than the
alternative, which is to say that there is always a base URI; i.e.
to figure out the abstract form of a SPARQL query string, you're
always given a base URI.

That's the route that XML infoset went, and it works reasonably

> > ACTION: EricP to add test in 0096 to rq23 tests. label "approved" and ref
> >
> > ACTION: ericP to send [OK?] message to Bjoern
> waiting to see if this text is OK.
> [SYNTAX] <>
> [COMMENT] <>
Dan Connolly, W3C
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Wednesday, 17 August 2005 23:03:52 UTC