[
Lists Home |
Date Index |
Thread Index
]
Rick Jelliffe wrote:
> Another approach is to build in a profiling system into XPath 2, on
> the assumption that everyone may need to customize it for particular
> uses anyway: XSLT would like a medium amount, XML Schemas key/unique
> would like a streamable subset, Schematron is happy with whatever
> comes along (as long as that daffy "optimization" is defeatable).
I agree. If people are using the same basic language, they should be
able to use the same parsers and processors for that language,
creating tailored XPath languages for their particular applications.
Off the top of my head, I think that this could be achieved with:
- a small core XPath module for streaming applications, tightly
restricted by:
- ignoring comments and processing instructions
- supporting only the child, descendant and attribute abbreviated
axes
- lacking predicates
- supporting only the built-in XML Schema data types
- plug-in sets of axes, which might be split into:
- axes that can be supported in streaming applications
- the rest of the axes
- ... possibly other application-specific sets of axes, as
required by particular languages or particular users ...
- plug-in function modules, which might usefully be broken up into:
- functions that give access to XPath static and dynamic
context, (e.g. position(), currentDateTime(), function-available())
- basic XPath 1.0 functions
- calculation functions (e.g. avg(), min(), max() -- ref. XForms)
- formatting and parsing functions (e.g. format-number(),
format-date(), regular expression functions)
- ... other modules as required by particular languages or
particular users ...
- other optional packages of features such as:
- PSVI information and functions
- dynamic evaluation
- support for functional programming
- ... and so on ...
The XPath 2.0 WD states:
XPath is designed to be embedded in a host language such as [XSLT
2.0] or [XQuery].
I think there are two things to point out here.
First, it's only "such as" XSLT 2.0 or XQuery. There are other
languages that use XPath. In particular, I think that once XPath in
DOM gets finalised, there will be a lot of use in that context in
particular -- people already take advantage of MSXML's
selectSingleNode() and selectNodes() methods rather than using DOM
methods to move through a node tree, and that use can only grow as it
becomes standardised. We've also mentioned XForms and XPointer, and I
don't think we should underestimate how often people use XPath
directly in their own languages (e.g. we see lots of "generic page
specification" languages on XSL-List -- this is one of the reasons
that dynamic evaluation functions are so important to XSLT users).
I think that it's clear that there's not going to be a
one-size-fits-all approach in XPath 2.0 that suits every host
language, and I believe that the correct approach to that is to
support modularisation and customisation rather than thinking that the
XQuery approach happens to be the correct one, or the XQuery goals and
requirements the most important ones, and so everyone should use it.
The second thing is that the above sentence reveals where XQuery
should stand in relation to XPath -- it should be a host language.
Like all the other languages that play host to XPath, it should
specify where XPath is used within it and which parts of XPath it
extends. It should be in a separate document. It should be that XQuery
*uses* XPath, just like the other host languages. The subset
arrangement that's used currently might be helpful editorially, but it
creates the impression that the W3C thinks that XSLT is using a subset
of XQuery, rather than that both are using the same core language of
XPath.
XPath shouldn't be the crumb that's swept off XQuery's table to feed
the whining XSLT lapdog, it should be the varied platter from which we
can all feast, as equals.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
