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 said neither "I'm confused" nor "you're confused".  I said "there is some 
confusion here".  The three mean distinct things.

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

Yes, but not legal XPath 1.0, which would mean that all implementors would 
have to retrofit not just extensions, but their XPath implementation cores 
with entirely speculative syntax.

Why would anyone go this byzantine route when they can just allow XSLT control 
structures?

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

I proposed a functional rather than a structural constraint, which would mean 
absolutely no damage to existing XSLT content model.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@xxxxxxxxxxxxxxx               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python



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