RE: comments on XPath 2.0

Allow me to make some personal comments, not on behalf of either WG:

> -----Original Message-----
> From: Vun Kannon, David [mailto:dvunkannon@kpmg.com]
> Sent: 04 January 2002 19:41
> To: www-xpath-comments@w3.org
> Subject: comments on XPath 2.0
> 
> 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.

I'll leave this one to those who have more experience of XML Schema than I
do.
> 
> Dereference (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.

XPointer or XLink? In either case, I'm concerned that these would greatly
add to the size of implementations. My preference would be to handle these
with function libraries outside the core XPath language. Inclusion of
functions that support XML Schema key and keyref seems more reasonable to
include in the core. 

> 	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.

We've had trouble getting agreement to include an evaluate() function at the
XSLT level: there's currently an issue against it in the XSLT 2.0 draft. In
my view there's no doubt that the requirement exists. Getting agreement to
include it in the XPath core will probably be even harder than getting
agreement at the XSLT level. There are some technical details to resolve,
such as the evaluation context for the expression (e.g. namespaces,
variables, context node), but I think the biggest problems are (a) the fact
that some implementations want to compile to executable code and don't want
to carry the overhead of having a full XPath interpreter around at run-time,
and (b) that use of an evaluate() function kills static type-checking and
optimization. For these reasons, it will probably always be an optional
facility that some implementations may omit.
> 
> 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/>.

I think you're right, these examples were carried over from XQuery into
XPath and should have been changed.
> 
> 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.

In principle I agree with you, but only where the semantics are those of a
function call. Here, I don't think we allow an arbitrary expression as
"$foo" - we can't, because types aren't first-class objects in the data
model, the value of an expression or of a variable can never be a type. In
fact, it's generally true that moving to more use of functions and less use
of keywords is inhibited mainly because neither types nor functions are
currently in the data model as first-class objects, which means types and
functions can't be passed as arguments to functions. I'm personally a fan of
enriching the data model to fix this problem, but it's a substantial change
and I think the group as a whole is reluctant to go this way in this version
of the spec.
  
> 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.

The current status is that the group decided not to do this. A use case that
shows why it's needed might be helpful.
> 
> XQuery closure
> 	If a query can construct elements and attributes, it 
> should be able
> to create the appropriate types as well.

I'm not sure I understand what you're asking for.
> 
> 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
> 
It's certainly true that you can now write some big XPath expressions; in a
sample stylesheet that I issue with Saxon 7.0, there's one that extends to
20 lines or so. My current feeling, though, is that "fine-grained" markup of
an XPath expression (as done in XQueryX) is overkill.

Mike Kay

Received on Monday, 7 January 2002 06:37:14 UTC