W3C home > Mailing lists > Public > public-qt-comments@w3.org > August 2009

[Bug 6131] [XPath 2.1] Requirement: context-free paths

From: <bugzilla@wiggum.w3.org>
Date: Sat, 22 Aug 2009 19:08:16 +0000
To: public-qt-comments@w3.org
Message-Id: <E1Mevwm-0005NT-35@wiggum.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6131


Nikolay Ognyanov <nikolay.ognyanov@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nikolay.ognyanov@gmail.com




--- Comment #22 from Nikolay Ognyanov <nikolay.ognyanov@gmail.com>  2009-08-22 19:08:15 ---
There are multiple rules where ExprSingle can be followed by "keyword" which is
not really reserved and can, depending on the context, also represent NCName.
With computed constructors and some other expressions ending with a curly
bracket construct there are lot of opportunities to invalidate currently valid
XQuery 1.0 expressions by treating everything which looks like a Clark name as
Clark name. Excluding whitespaces does not really help because in the
situations mentioned above they are allowed but not required. Here is an
example :

for $a in element b {scheme:path-rootless}return c

This perfectly valid XQuery 1.0 expression would be invalidated if
"{scheme:path-rootless}return" is treated as Clark name. At the same time
XQuery 1.1. requirements mandate 100% backward compatibility with XQuery 1.0 by
saying "Every valid XQuery 1.0 expression MUST be valid in XQuery 1.1 and it
MUST evaluate to the same result.". So unless backward compatibility
requirements are relaxed (which does not seem very likely or/and very good
idea), Clark names can not be introduced in XQuery 1.1. the way suggested above
even regardless of other issues which could be brought up. This is a pity but
curly braces are so widely (over)used in XQuery and its extensions that
introduction of new "naked" curly bracket constructs seems to always turn out
harmful one way or another and even curly bracket constructs guarded by
lead-in/follow-up words can cause problems, especially when those words are
reused in multiple rules.

The syntax that I would vote for is :

EQname: QName | UriLiteral ':' NCName   /* ws:explicit */

It is very similar to the initial suggestion but does not introduce new
delimiter and UriLiteral is already in use in XQuery, so it should better be
reused here.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Saturday, 22 August 2009 19:08:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:40 UTC