RE: comments on XPath 2.0

Hi David,

Thanks for your comments on XPath 2.0. The use cases for XBRL 2.0 do seem to
be directly related to some of the issues that we've encountered in XPath.
Thanks for pointing them out. We will take your comments into account as we
go forward in the recommendation process.

Regards,

Zarella Rendon
for the W3C XSL WG


> -----Original Message-----
> From: www-xpath-comments-request@w3.org
> [mailto:www-xpath-comments-request@w3.org]On Behalf Of Vun Kannon, David
> Sent: Friday, January 04, 2002 1:41 PM
> To: 'www-xpath-comments@w3.org'
> Subject: comments on XPath 2.0
>
>
> 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 Saturday, 5 January 2002 22:41:23 UTC