[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Designs for XSLT functions (Was: Re: RE: syntax su
Hi David, > It would by syntactically XPath 1.0 but not semantically, so you can > still not call it XPath 1.0. And if you are considering leaving the > pure XPath 1.0 track it would be a small step implementationwise to > have another syntax, though the particular syntax isn't that > important here I think. One thing to consider though: if it by > definition doesn't behave like an extension function, it probably > shouldn't look like one. Well OK, and I think that this is a good argument for not restricting ourselves to only variables in the body of exsl:function. Personally, I think that any kind of extensions to XPath are beyond what can be legally done to extend XSLT. I am not sure that (other) implementers would respond positively to the idea of having a different, XPath-like syntax within a particular attribute in an extension function. I also think that it would be hard to explain to newbies why this particular attribute uses a slightly different syntax (or rather why they can't use (.. ? .. : ..) in the rest of their code. > I think the important thing is that you have dedicated numerous of > postings to try figuring out what should be allowed and not > in the body of an exsl:function and in my opinion you haven't got > close to the end. I'd say it isn't trivial to know that we've > covered all the possible cases. Whereas with my proposal, > the definition is straightforward and the implementation is > straightforward. But maybe that's too boring :-) Oh, certainly too boring ;) The main reason that I disagree with your proposal is that I am *certain* that it *doesn't* cover all the possible cases. For example, I cannot see a way to create the key function that I want to create using your restricted syntax. Show me how to create a key function with the arguments: my:key(string, object, node-set, node-set?) where the first two arguments are the normal arguments to key() and the second two are the normal arguments to document() (but with the third always a node-set rather than having the possibility of being a string). It should return the nodes that result from using the key with the document(s). I know that this will be possible in XPath 2.0. All things will be possible in XPath 2.0 :) (Including some kind of conditional construct.) > I don't see how messing around with XSLT instruction semantics can > be any more fruitful than a couple of simple add-ons to XPath in a > well defined place: exsl:result/@select. But then, the beauty is in > the eye of the beholder :-) As you imply, I think we'll probably have to agree to disagree on this. Personally, I find messing around with extension elements more acceptable than messing around with XPaths. Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|