This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Evaluating XPath expressions found in the source document


Hi Michael,

> I mean, the subset of XPath expressions I had mistakenly taken to be
> the entire set are simply abstract notations of how to identify a
> node from a known starting point. All they need in the real world is
> a possibility of there being a instance of a tree that fits them.
> But concat(), though it too is an abstraction, is one whose
> realisation requires a machine somewhere that knows how to do things
> to the data. And where is that machine, if not in the XSLT
> processor? But if that is in indeed where it is, how is
> format-number() different from concat() in terms of what can
> actually be done to what and where?

Hmm... When you think about a location path as an XPath expression,
then I think there's no big difference between that and a function.
They are both string representations that, when evaluated, return
something. A location path returns a node set; some arithmetic returns
a number; a function call might return any of the XPath object types.
You always have to have a processor of some description that will
parse and evaluate that XPath for you, if you want to do anything with
it.

You're right that XPath expressions, when used in XSLT, are evaluated
by an XSLT processor. But XPath stands on its own as a Recommendation
and is incorporated into a lot more than XSLT, such as XForms and
XPointer. You could imagine having a specific XPath processor that
plugs into XSLT, XForms and XPointer processors.

>From what I can make out, the functions that are defined in XSLT are
somewhat special because they are tied up with how XSLT processes
documents; similar functionality might not be useful in XForms or
XPointer, or might require additional support that isn't available in
those languages. Certainly I can see that with some of them:

 * key() - relies on xsl:key
 * format-number() - relies on xsl:decimal-format
 * current() - tied in with the XSLT processing model
 * system-property() - tied in with the fact you're using XSLT
 * element-available() - only applies to XSLT elements

Others I'm not so sure about:
 
 * document()
 * unparsed-entity-uri()
 * generate-id()
 * function-available()

but perhaps someone from the WG will be able to shed light on why
they're defined in XSLT rather than XPath.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]