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

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

From: <bugzilla@wiggum.w3.org>
Date: Wed, 08 Jul 2009 08:10:55 +0000
To: public-qt-comments@w3.org
Message-Id: <E1MOSEx-0001AN-JO@wiggum.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6131





--- Comment #6 from Michael Kay <mike@saxonica.com>  2009-07-08 08:10:55 ---
Comment #4 suggests syntax that looks reasonable enough if you approach the
problem from an XQuery perspective. But in proposing this approach, we were
looking at the problem primarily from the point of view of XPath use cases, and
the syntax feels very clumsy at the XPath level. For a start, it introduces
curly braces to XPath for the first time, which is a significant disadvantage
for some of the environments where XPath is embedded (for example, XSLT) -
though not necessarily insuperable.

A major part of the rationale for introducing an EQName syntax, however, was
that it could be widely adopted anywhere that QNames are currently used - not
only in XPath. For example, some XML vocabularies such as XSLT and XSD make
wide use of QNames-in-content in contexts other than XPath, and these share the
same requirement to be written in a context-free way. Obviously adoption of
EQName syntax would be on a case-by-case basis, but including it in XPath as a
first step, and in XSLT soon after, would set a precedent that I think other
specs might well choose to follow.

An alternative that was considered was to use Clark names in the format
{uri}local. These are already used in a number of interfaces, for example in
Java APIs. If the only objection to the proposal is the use of backtick, then
perhaps we should consider using Clark names instead. They have the advantage
of familiarity and precedent. The reason I recommended using backtick-syntax
instead was that the curly braces cause problems in certain syntactic contexts.
In particular they cause problems when used in an XSLT attribute value
template, especially if the left-curly is the first character.

We also considered the convention used for turning error code QNames into plain
strings, namely uri#local. This convention fails (or at any rate, becomes very
confusing) if the namespace name contains a "#"; unfortunately namespace names
containing "#" are not only only legal, they are common practice in the RDF
community. Another disadvantage of this as an EQName syntax is that it's not
readily recognized by an XPath tokenizer: the URI needs to be delimited in some
way.

(Note: a namespace name should be a legal IRI, though our specs and
implementations tend to be tolerant of namespace names that are not legal IRIs.
The only characters that are illegal in an IRI are "<", ">", '"', space,
 "{", "}", "|", "\", "^", and "`". But it would be safer to have a syntax that
allows any string to be used as a namespace name, which means that there is a
need to escape whatever end-delimiter is used.)


-- 
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 Wednesday, 8 July 2009 08:27:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:27 UTC