Re: IRI text, addendum

Michael Kifer wrote:

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

I agree that this paragraph concerns the concrete to abstract syntax 
step and is out of place at the moment. I was just trying to capture it 
so that readers were aware that this will be provided for when the specs 
are complete; on the understanding that it will later be moved into the 
right place.

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

Not quite. The "no implied equalities" applies to the normalized IRI 
string, the thing that ends up in the abstract syntax. We've just spend 
some time discussing the many normalization levels that the specs 
provide for and confirming that we should stick to the basic level (i.e. 
just Normal Form C). It seemed worth spelling that out.

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

Nonsense. I wasn't talking about linguistic style, I was talking about 
the precise selection of the RFC sections to reference to define the 
processing steps. SPARQL's choices will be reviewed by the external 
reviewers, I18N et al ahead of our spec. If their choice of references 
passes review then it makes sense to me to pick the same set.

Given that the specs spell out a range of possible options we do need to 
reference which ones we pick. If you want to also explain those 
references in-line to make your document more standalone then you can do 
so but such a section would need to be clearly labelled "informative" 
rather than "normative". Precision, when you are talking about an 
external spec, boils down to a clear set of references.

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

A week ago the proposed text said basically that for IRIs. There was 
some unhappiness about what the implication of selecting IRIs meant and 
how they interoperate with URIs. Those implications are totally bound up 
in the choice normalization/mapping steps. We've just spent lots of 
emails pinning down the answer to that, in part by careful reference to 
the RFCs. Yes our end choice is the trivial one, but that wasn't obvious 
to everyone a week ago. It seemed to me useful to capture that in actual 
text in the spec so that implementers are as clear as we are now and not 
as potentially confused as we were a week ago.

Yes it is really to do with the concrete syntax rather than the sort 
definition, but it is common across the XML and human readable syntaxes, 
will need to go in the document sometime and seemed worth putting in a 
place holder now.

However, this is not urgent or that big a deal. If you are not happy 
with the proposed text then leave it out. When we come to the next WD, 
which will hopefully be clearer on the concrete syntax, we can review 
whether these aspects are adequately covered by whatever text does end 
up on there.

Dave

-- 
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Thursday, 19 April 2007 09:07:19 UTC