Subject: Re: [xsl] RE: Designs for XSLT functions From: David.Rosenborg@xxxxxxxxxx Date: Tue, 20 Feb 2001 17:41:50 +0100 |
> > > 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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] RE: Designs for XSLT func, Uche Ogbuji | Thread | RE: Designs for XSLT functions (Was, Michael Kay |
RE: [xsl] Converting RSS to HTML, Michael Kay | Date | [xsl] Numbering Grouped Child Eleme, Jake Stevenson |
Month |