W3C home > Mailing lists > Public > www-xpath-comments@w3.org > January to March 2002

comments on XPath 2.0

From: Vun Kannon, David <dvunkannon@kpmg.com>
Date: Fri, 4 Jan 2002 14:40:34 -0500 (EST)
Message-Id: <53A3C10BA714D511BA9300805FA7FB2A051125F5@usmnyexc05.us.kworld.kpmg.com>
To: "'www-xpath-comments@w3.org'" <www-xpath-comments@w3.org>
I am submitting comments which reflect my own personal concerns as well as
those stemming from my participation in XBRL as an editor of the XBRL
specification.

Comments related to previously assigned issues:

Substitution groups (issue 49)
	XBRL 2.0 (to be published imminently on the www.xbrl.org site) uses
the substitution group functionality of XML Schema extensively. XBRL
taxonomies are specially constructed XML Schemas in which most elements
belong to the xbrl:item substitution group. Therefore, a common query on
XBRL instance documents will be to find all elements belonging to the
xbrl:item substitution group. For example //*[sGroup("xbrl:item")]

Dereferece (issue 134)
	XBRL 2.0 use key/keyref where appropriate, and would use it more if
it supported more of XPath (a separate issue!). XBRL 2.0 also uses XLink
extensively. An awarenes of key/keyref and XLink semantics would be useful
in XPath 2.0.
	As a follow-on, to me this issue seems to be one of indirect
addressing. The value of one node is interperted as the address (in some
sense) of another node or set of nodes. Besides idrefs, keyrefs, and XLinks,
the most common form of indirect addressing is an XPath expression itself.
Yet there is no eval() function in XPath. For example
eval("template/@select") should return all the nodes returned by the XPath
expression held in the template element's select attribute.

Editorial comment

Section 2.4.2
	The examples discuss elements instead of nodes in general. As a
result, sequences such as (<a/>, <b/>) are discussed. Since <a/> is a
concrete syntax, this gives the impression that (<a/>, <b/>) is a concrete
syntax. The examples here could just as easily discuss nodes a, b, c instead
of elements <a/>, <b/>, and <c/>.

General comments

keywords vs functions
	XPath 2.0 claims to be a functional language. I believe it would
benefit from a more functional style in places. I would prefer to parse
elementOfType( $foo ) instead of "element of type $foo". One non-trivial
reason is that the keyword version is very obviously English. At least with
the functional version, I have a clue that I should put aside my
understanding of the natural language words. Or just change the keyword
structure to Japanese - "type no element $foo".

Simple datatype testing
	Simple datatype have facets and properties. This structure should be
testable. For example, find all elements whose type has a maxlength less
than 50.

XQuery closure
	If a query can construct elements and attributes, it should be able
to create the appropriate types as well.

Expression size
	The need to invent a new comment syntax to be embedded inside XPath
expressions is a clue that the expressions are too big. So are constructs
such as for and if. 	As I suggested for XPath 1.0, there should be a
version of XPath 2.0 in XML. Benefits:
		Standard tools work with it. Can write it easily with XSLT.
		Can write an XML Schema for it.
		Can point into it easily with XLink and itself.
		Can document it with standard comments.
	The use of the sublanguage in XSLT and XQuery should allow reference
to the XML version of an XPath expression as well as the an XPath expression
as attribute content

Cheers,
David vun Kannon
Senior Manager, KPMG LLP
*****************************************************************************
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized. 

If you are not the intended recipient, any disclosure, copying, distribution
or any action taken or omitted to be taken in reliance on it, is prohibited
and may be unlawful. When addressed to our clients any opinions or advice
contained in this email are subject to the terms and conditions expressed in
the governing KPMG client engagement letter.         
*****************************************************************************
Received on Friday, 4 January 2002 16:47:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 3 October 2007 16:05:54 GMT