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.

We can place it somewhere in the endnotes then.
There is an even more pressing need to define IRI prefixes, which we use,
but do not define.

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

We didn't talk about normalized IRIs, but IRIs as sequences of characters.

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

I wasn't talking about the linguistic style either, but about the fact that
instead of saying a very simple thing in one sentence the paragraph sends
the reader on 3 lengthy detours.

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

If all we are saying is that two IRIs that are represented by distinct
sequences of characters are distinct then we don't need any external
references. I would be happy to clarify this even further (parenthetically)
by saying that no normalizations or other equivalences mentioned in the
RFCs are to be used).


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

This is precisely my point. The documents are written in a convoluted
manner, which purports to be precise, but really isn't. It takes several
people and a lengthy discussion to more or less agree and understand what
the authors of the document might have meant.

But once we went through this exercise, there is no good reason to subject
our own readers to the same kind of trial.


	--michael  


> 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:26:29 UTC