Re: Designs for XSLT functions (Was: Re: RE: syntax su
Hi Jeni, > > 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. Sorry, you lost me there, how do you mean these things are related? > 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. What do you mean by legal? My proposal is certainly legal XSLT 1.0. In fact, if we loosen the concept of legality a bit I could argue that changing the constraints on XSLT instuctions would be illegal unless you put them in a new namespace. (Strictly speaking they are legal since there are no constraints what so ever on the contents of an extension or top level element). What I'm saying is that if you changed your proposal to use exsl:choose, exsl:for-each etc then this would be better since then you would be defining a completly new languge to deal with node set (and other primitive XPath types) functions. This instead of trying to retrofit XSLT instructions into something they were not designed for. > 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 admit this can lead to some confusion, though I think the confusion would be an order of magnitude smaller than that caused by retrofitted XSLT instructions. > The main reason that I disagree with your proposal is that I am > *certain* that it *doesn't* cover all the possible cases. Since you, in my opinion, haven't got even halfway setting the semantics of you proposal I think claims for full coverage are too early to make. (well you didn't explicilty claim it, I just sensed an implicit comparison). In fact, I don't see any proposal that could cover all possible cases. (mostly because "all possible cases" is a bit underspecified :-) I suggest that you start with a small, clean and well defined core. Use it for a while. Discover what's missing. Design equally clean and well defined improvements and add them to your language. Going for the big bang directly can be devastating. > 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?) No, I cannot, though I would be glad to do a test implementation of the document (...)/key (...) functionality found in XPath 2.0. (now, my implementaion is not in public domain so it wouldn't help you much, sorry :-) I think this raises an important issue: It has been said earlier on this thread that one purpose of this effort is to explore new functionality that could possibly make its way to new versions of XSLT and XPath. Maybe I'm blind, but I just can't see the logic in evaluating new possible extensions to XPath by trying to implement them with retrofitted XSLT instructions. For the XSLT part it's OK, but for XPath it just doesn't make sense. It seems like many of you think XPath is untouchable, holy ground, whereas XSLT is not. I don't really see why you are making that distinction. Albeit we would have to go over an extension function call to test new XPath constructs from arbitary places in our stylesheets, this doesn't justify not implementing XPath extensions in XPath rather than in XSLT instructions. (The function call is necessary since the experimental XPath may only appear as a descendant to an extension or top level element) > 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. Well, sorry, the mutal-disagreement-escape won't stop me from arguing :-) Cheers, </David> David Rosenborg Pantor Engineering AB 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