This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: RE: Designs for XSLT functions
- TO: uche dot ogbuji at FourThought dot com
- Subject: Re: [xsl] RE: Designs for XSLT functions
- From: David dot Rosenborg at pantor dot com
- Date: Tue, 20 Feb 2001 16:50:05 +0100
- CC: mhkay at iclway dot co dot uk, xsl-list at lists dot mulberrytech dot com
- Reply-To: xsl-list at lists dot mulberrytech dot com
> > Hmh, I think you missed my point about having a conditional
> > construct in XPath.
>
> [snip illegal XPath 1.0]
>
> I think there is some confusion here.
Well, I'm not confused, are you? ;-)
> I think it's most useful to stay within the bounds of legal XSLT and XPath
> 1.0, especially since I think all we want has been demonstrated as possible
> within those bounds. After establishing things a bit, we can work up an
> informed wish-list of XSLT/XPath > 1.0 enhancements with respect to XSLT-
based
> extension functions.
As I said in an earlier post:
an attribute on a top level or extension element can contain
an enhanced XPath and it would still be perfectly legal XSLT 1.0.
What I'm arguing is that a couple of non-intrusive extensions
to XPath is preferable to an intrusive mix of XPath and XSLT
instructions. Intrusive in the sense that it changes
constraints on existing XSLT instructions.
Preferable from a definition perspective:
* simply define the XPath extensions, no need to create a
list of restrictions to existing XSLT instructions.
Preferable from a usage perspective:
* Only have to learn a few new XPath extensions, everything else
work as before.
* There will be no confusion about when a RTF is returned and
when a node set is returned. In XSLT 1.1 this would be a slightly
smaller issue with implicit RTF->node set conversion but you would
still have differences, like the root node, base URI, performance
etc.
Preferable from an implmentation perspective:
* No need to interfer with the execution model of template instructions.
* Pure XPath extensions are easy to implement, at least in my experience.
Cheers,
</David>
David Rosenborg
Pantor Engineering AB
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list