> > > 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
| Current Thread |
- Re: RE: Designs for XSLT functions, (continued)
- David . Rosenborg - Tue, 20 Feb 2001 03:27:01 -0500 (EST)
- Uche Ogbuji - Tue, 20 Feb 2001 10:08:29 -0500 (EST)
- David . Rosenborg - Tue, 20 Feb 2001 10:51:36 -0500 (EST)
- Uche Ogbuji - Tue, 20 Feb 2001 11:12:23 -0500 (EST)
- David . Rosenborg - Tue, 20 Feb 2001 11:42:45 -0500 (EST) <=
- Michael Kay - Mon, 19 Feb 2001 17:38:35 -0500 (EST)
- Jeni Tennison - Tue, 20 Feb 2001 09:38:04 -0500 (EST)
- Uche Ogbuji - Tue, 20 Feb 2001 09:48:54 -0500 (EST)
- Steve Muench - Mon, 19 Feb 2001 02:08:13 -0500 (EST)
|
|