Re: IRI text, addendum

Michael Kifer wrote:
>>We started to discuss this on the call today but shelved it while I 
>>found the text and never got back to it ...
>>
>>My original proposed text [*] relating to issue 30 actually had two 
>>paragraphs. We've covered the first one. The second one mentioned the 
>>resolution of relative IRIs into absolute IRIs.
>>
>>Is there any reason to not also include this second paragraph?
>>
>>Checking the SPARQL spec, which is where the substance of this text came 
>>from, I see one more sentence would be useful, so the revised proposed 
>>second paragraph is:
>>
>>[[[
>>In the concrete XML and human readable syntax relative IRI references
>>are permitted in which case they will be resolved relative to a base IRI
>>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) are 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].
>>]]]
>>
>>This does two things. Points out that you can use relative references in 
>>source documents (they become absolute IRIs in the abstract syntax). 
> 
> 
> This reference to relative URIs is out of place here. When and if we
> introduce syntax for relative URIs and define the exact macro processing
> for them then we will talk about it.
> 
> 
>>Spells out that there is no normalization step, which implies that 
>>equivalence is the simple string comparison that we've discussed in email.
> 
> 
> This is already captured in a more precise way when we said that there are
> no equalities implied for the sort of the uris.
> 
> 
> 
>>If we would like to capture that sentiment but wanted text that 
>>separated those two issues more clearly I could draft that but the above 
>>has the advantage that if it's good enough for SPARQL then it's good 
>>enough for us.
> 
> 
> I don't think that what is good for SPARQL is good for us.
> The SPARQL document is full of rather vague pieces, which I hope we will
> avoid.

Some of which I also mentioned in the review sugggestion... if you have 
more, please let me know.

> It is also replete with external references, which makes it hard to
> understand without lengthy detours. The paragraph you quoted above is a
> good example of this sort of a bad style.

I wouldn't thought have considered that one as problematic, though.
It might be said simpler though, as you suggest...

> Why not simply say that two URIs are distinct if they are not identical?
> Instead, the paragraph invokes the normalization stuff,

... but well, the only normalization I see here is resolution of 
relative IRIs, right? As you mentioned above, you don't seem to disagree 
that we can proceed the same way:

 > When and if we introduce syntax for relative URIs and define
 > the exact macro processing for them then we will talk about it.

I don't see how/why the preprocessing in RFC3986, sec 5.2 would
contradict this or why it wouldn't be a valid candidate?

thanks for clarifying
axel


> the unreserved
> characters crap, and 3 external references!
> 
> 
> 	--michael  
> 
> 
>>Dave
>>
>>[*] http://lists.w3.org/Archives/Public/public-rif-wg/2007Mar/0133.html
>>-- 
>>Hewlett-Packard Limited
>>Registered Office: Cain Road, Bracknell, Berks RG12 1HN
>>Registered No: 690597 England
>>
>>
>>
> 
> 
> 
> 
> 
> 


-- 
Dr. Axel Polleres
email: axel@polleres.net  url: http://www.polleres.net/

Received on Thursday, 19 April 2007 01:46:44 UTC