- From: Michael Kifer <kifer@cs.sunysb.edu>
- Date: Wed, 18 Apr 2007 11:31:17 -0400
- To: Dave Reynolds <der@hplb.hpl.hp.com>
- Cc: RIF <public-rif-wg@w3.org>
> 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. 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. Why not simply say that two URIs are distinct if they are not identical? Instead, the paragraph invokes the normalization stuff, 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 > > >
Received on Wednesday, 18 April 2007 15:35:27 UTC