Re: RE: Designs for XSLT functions

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