Re: QName production in SPARQL grammar [OK?]

On Tue, 2005-12-13 at 12:12 +0000, Jeremy Carroll wrote:
> http://www.w3.org/TR/2005/WD-rdf-sparql-query-20051123/
> The third comment would have substantive consequences, the other three 
> comments are editorial.
[...]
> COMMENT 3: Minor change to NCNAME production
> ============================================
> 
> My understanding is that these productions are taken from XML 1.1, and 
> modified to:
> 
> a) prohibit _ as a namespace prefix, because of confusion with blank nodes
> b) prohibit a trailing '.' because of syntactic confusion with '.' as a 
> SPARQL puncutation character.
> c) permit ':' and 'prefix:' and ':name' as QNAMEs
> (I am not quite sure why, maybe compatibility with N3?)
> 
> I am unclear as to why these changes were made while maintaining 
> restrictions from XML 1.1 that are not applicable in the SPARQL context. 
> The most striking is the prohibition on digits immediately after the :.
> This prevents an IRI such as:
> 
> urn:newsml:iptc.org:20001006:topicset.iptc-subjectcode:16
> 
> being abbreviated by the QNAME production.
> 
> 
> I suggest a fix of replacing production 90
> http://www.w3.org/TR/2005/WD-rdf-sparql-query-20051123/#rNCNAME
> 
> OLD
> [[
> [90]    	NCNAME  	  ::=    	NCCHAR1 ((NCCHAR|'.')* NCCHAR)?
> ]]
> 
> NEW
> OLD
> [[
> [90]    	NCNAME  	  ::=      ((NCCHAR|'.')* NCCHAR
> ]]
> 
> This maintains the restriction that the NCNAME production does not end 
> in a '.', and is non-emtpy, but removes the restrictions on the first 
> character, and would allow abbreviations of IRIs that end in a non 
> NCCHAR followed by a sequence of digits.

The working group considered details such as these in discussion
of the punctuationSyntax issue.
 http://www.w3.org/2001/sw/DataAccess/issues#punctuationSyntax

As you can see from the history of this issue, we considered a number
of designs and a number of details; our latest decision, 2005-06-07,
was based on a collection of some 70 tests that cover details such
as the details of URI short-hands. While the specific context
of using SPARQL for newsml isn't something we considered, the
question of what characters are allowed in URI short-hands
was considered, and, after considering advice from WG members,
I don't think it's worthwhile to re-open the issue at this late date.

I hope you find this response satsifactory. Please let us know
whether you do.

If are satisfied, putting [closed] in the subject will save
us a small amount of bookkeeping.


This response is not meant to preclude the editors from acting
your editorial suggestions.



> ===================
> 
> 
> I had four comments to make mainly about the QNAME production and 
> related productions in the SPARQL grammar.
> 
> http://www.w3.org/TR/2005/WD-rdf-sparql-query-20051123/#rQName
> 
> http://www.w3.org/TR/2005/WD-rdf-sparql-query-20051123/#rQNAME
> 
> http://www.w3.org/TR/2005/WD-rdf-sparql-query-20051123/#rQNAME_NS
> 
> The overall thrust of the comments is to support the use of
> eg:name as an abbreviation mechanism, and to clarify its relationship 
> with the qname production from XML Namespaces.
> 
> 
> COMMENT 1: [NAMESPACE] reference
> ================================
> 
> I note that the [NAMEPSACE] reference is informative not normative.
> However, the sentence in which it is used:
> "The PREFIX keyword binds a prefix to a namespace IRI [NAMESPACE]. "
> has a most natural reading in which a PREFIX cannot be used to bind a 
> prefix to an IRI that does not identify a namespace (this reading would 
> require a normative reference).
> Given that the reference is informative I take that reading to not be 
> the intended reading.
> This sentence could hence be clarified by the editorial change of:
> "The PREFIX keyword binds a prefix to an IRI. "
> and deleting the [NAMESPACE] reference
> 
> I also note that the example use of PREFIX:
> 
> PREFIX  data:  <http://example.org/foaf/>
> 
> does not bind a prefix to a namespace IRI, but does bind a prefix to an IRI.
> 
> 
> COMMENT 2: redundancy in grammar
> ================================
> 
> I think the following editorial change leaves the language wholly 
> unchanged, but slightly simplifies the grammar.
> 
> Change:
> 
> [64]    	QName  	  ::=    	QNAME | QNAME_NS
> [68]    	QNAME  	  ::=    	NCNAME_PREFIX? ':' NCNAME?
> 
> to
> 
> [64]    	QName  	  ::=    	NCNAME_PREFIX? ':' NCNAME?
> 
> and delete production 68.
> 
> 
> 
[...]
> COMMENT 4: Editorial change to rename productions
> =================================================
> 
> The use of the term QNAME for this production is confusing.
> A QNAME is defined in XML Namespaces as appropriate for XML elements and 
> attributes, for referring to a name from a namespace.
> 
> The use in SPARQL is an abbreviation mechanism, and not a mechanism for 
> selecting a name from a namespace, indeed as we have seen under comment 
> 1, the abbreviation need not identify a namespace. For example, the 
> following renamings would make that clearer, and would make it clearer 
> that the syntactic restrictions on this mechanism in SPARQL, while 
> similar to those for qnames in XML, are different.
> 
> QName            => Abbr_IRI
> QNAME            => ABBR_IRI
> QNAME_NS         => ABBR_IRI_PREFIX_COLON
> NCNAME_PREFIX    => ABBR_IRI_PREFIX
> NCNAME           => ABBR_IRI_POSTFIX
> NCCHAR1p         => ABBR_CHAR1p
> NCCHAR1          => ABBR_CHAR1
> NCCHAR           => ABBR_CHAR
> 
> 
> This would reduce the common confusion between the abbreviation 
> mechanism which is widely used in the semantic web community, and the 
> QName mechansim used in XML Namespaces.
> 
> 
> 
> 
> 
> 
> -------------------
> 
> Once again apologies for the lateness, these issues have struck me more 
> forcefully recently as a result of discussions concerning XHTML2, where 
> similarly there is a need for an IRI abbreviation mechanism, which 
> should be familiar, yet disjoint from bnode identifiers ...
> 
> 
> Jeremy

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Monday, 9 January 2006 19:00:01 UTC