RE: comments on XPath 2.0

Thank you for your comments.

After rereading the WD, I see that "element of type $foo" is not correct.
However, issue 197 uses this kind of syntax, so I may have been misled
there. I agree that it would be better to have a data model in which types
and functions were first class objects.

I agree that evaluate() may be more appropriate in the function set of XSLT
than core XPath, but won't XQuery need it also? Xlink semantics could also
be a separate function library.

Here is a use case for testing facets. Find all the elements whose type
looks like a US Social Security number (123-45-6789). This is in distinction
to any text in the document which happens to look like an SS#. Searching
over a heterogenous collection of documents, what the schema author called
it is less important than the 'shape'.

Cheers,
David vun Kannon

-----Original Message-----
From: Kay, Michael [mailto:Michael.Kay@softwareag.com]
Sent: Monday, January 07, 2002 6:37 AM
To: 'Vun Kannon, David'; www-xpath-comments@w3.org
Subject: 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 
*****************************************************************************
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 Tuesday, 8 January 2002 03:57:38 UTC