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

Seaborne, Andy wrote:
>>
>> 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.

Well, this is a small point, maybe vanishingly so.  I had in mind an 
implementation that operates in multiple phases, something like:
   (a) build parse tree
   (b) scan parse tree and build a directory of prefix URIs
    :
and later:
   (.) process qnames from parse tree, using the directory to 
re-interpret them as URIs.

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

Interesting:
- in the case of XML, I believe xmlns prefix redefinition is only 
allowed within nested scopes, and a prefix cannot be redefined at the 
same level.
- I wasn't aware that N3 allowed prefoixes to be redefined.  My own 
implementations have not, but instead raise an error on encountering 
such.  I guess that's why I was surpised by this design choice.

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

Roughly, yes.  My recollection is that RDF takes this on board by 
requiring NFC be applied prior to constructing a representation of the 
RDF abstract syntax.  I don't know enough to pursue this point indetail; 
  I raised it in case it had been overlooked.

#g

-- 
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Received on Tuesday, 13 September 2005 07:42:42 UTC