Subject: Re: Designs for XSLT functions (Was: Re: [xsl] RE: syntax sugar for call-template) From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx> Date: Wed, 21 Feb 2001 09:47:01 +0000 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Designs for XSLT functions (Was, David . Rosenborg | Thread | Re: Designs for XSLT functions (Was, Michael Beddow |
Re: The top 10 limitations of XSLT , Michael Beddow | Date | RE: [xsl] XQuery (was Designs for X, Dylan Walsh |
Month |