Re: Comments on last-call SPARQL draft 20050721, section 2

Graham,

Thank you these comments - a couple of questions inline:

Graham Klyne wrote:
> [Unfortunately, the last-call period for this coincided with a period of 
> extended unavailability for me, so I'm rather late getting my comments 
> together.  So far, I've got comments on section 2;  I'll send in more 
> later if I can get them in on time.]
> 
> ...

<snip/>

> 
> Section 2.1, "Query term syntax", para 4
> 
> I feel that allowing a prefix to be redefined as described could create 
> some small unnecessary complication for implementations that don't 
> process the query sequentially, and creates scope for implementation 
> errors.  I would suggest not allowing prefixes to be redefined.  Is 
> there a compelling case for allowing such redefinition?

Could you say more?  I'm having trouble understanding a SPARQL implementation 
that does not process the SPARQL grammar which is itself sequential.  Iguess 
the parser could be leaving qnames unexpanded in parsing for later resolution 
but that second pass over the query can be with the correct prefixes.  Because 
prefixes come before any qnames, it isn't the case there can be
  PREFIX ... qname ... PREFIX  Prefixes must take an quoted IRI reference.

(I believe the rational to allow redefinind prefxies was based on the 
observation that other systems do it and we saw no reason to be different 
(e.g. N3, XML namespace declarations)).

> 
> ...
> 
> Section 2.1, "Query term syntax", para 5
> 
> I'm a bit hazy on the details, but the discussion of combining 
> characters goes against my recollection that RDF specifies that 
> URI-references muct be in normal form C, which I think was intended to 
> avoid some of these issues.  I think that SPARQL should follow RDF in 
> the forms of URI/IRI that it allows.

SPARQL follows the IRI spec - my reading of that is that as a processor that 
is not responsible for creating the IRIs, it should not apply normalization 
(presumably because it needs to allow access to unnormalized data).

RFC 3987 (IRI) says: 5.3.2.2:

"""
Equivalence of IRIs MUST rely on the assumption that IRIs are
    appropriately pre-character-normalized rather than apply character
    normalization when comparing two IRIs.   The exceptions are conversion
    from a non-digital form, and conversion from a non-UCS-based
    character encoding to a UCS-based character encoding. In these cases,
    NFC or a normalizing transcoder using NFC MUST be used for
    interoperability.
"""

Does that agree with your understanding?

<snip/>


> 
> That's all for now.  I'll try and do some more later (but I'll be 
> travelling and may be unable to do so by the last-call deadline).

No problem - we'll still be here.

> 
> #g
> 

	Andy

Received on Monday, 12 September 2005 11:15:48 UTC