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 17:41:50 +0100
- CC: xsl-list at lists dot mulberrytech dot com
- Reply-To: xsl-list at lists dot mulberrytech dot com
> > > 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.
Well, now I'm confused :-)
> 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.
I've never claimed it to be XPath 1.0. In XSLT 1.0 you would allow the
extended XPath only in the select attribute of exsl:result
> Why would anyone go this byzantine route when they can just allow XSLT
control
> structures?
I think the answer lies in the comments you snipped out:
In my opinion it is much cleaner and simpler to implement
some add-ons to XPath (yes, they are by definition speculative!)
that would only be used in exsl:result/@select than
(equally speculaitve) intrusively changing or even rewriting the
execution model for template instructions.
Cheers,
</David>
David Rosenborg
Pantor Engineering AB
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list