> Hi Dave, > > > Re: <xsl:script>, I've done some more thinking about this, and have > > come around to the view that having a common binding per language is > > better than not having one. I would prefer not to see other > > languages inlined within XSLT source -- I take it that there must be > > a substantial user base that needs to have everything packages in > > one file instead of (for example) one per language? Support for an > > <xsl:binding>, without inline scripting, is about as far as I have > > swung so far. > > Thinking about client-side processing, I also wonder whether it > wouldn't be more efficient for the xsl:script elements to point to the > sources and let the processor decide which one(s) to download, given > the languages that that processor supports, rather than always > shipping the scripts in all those languages all over the place. That's how I'd do it. There would be a performance hit when the site is first visited -- or when the local cache is flushed -- as it grabs the ecmascript file or the java file or the msil file or whatever, but other than that I don't see a performance difference. I do see that it's a bit more work to do than simply inlining the foreign-language code, but I'm still inclined to think that that's a good thing. > > Finally, wouldn't it be useful for <xsl:function> to return multiple > > items? (Though I guess it would have to be called <xsl:relation> > > instead! :-) Sure, it is possible to encapsulate multiple values > > into a single one to get around this, just as it is in many other > > languages, but why create the need to? > > Actually I think it's pretty hard to encapsulate multiple values into > a single one in XSLT - how would you return a string, a number and a > node set without turning them all into an RTF? Unfortunately, I think > that supporting the return of multiple values either way would mean > extensions to XPath. Perhaps it's something worth lobbying for for > XPath 2.0. I think it's certainly inconvenient. Another commented that it could be done already (while snipping my "yes, I know it can be done already" comment!). You comment that it's pretty hard. I guess it's something for further debate. :-) Certainly, my approach given the status quo would be to construct an RTF containing all of the information that I wanted to return. It's already okay to have five <xsl:param> statements upon entry, so I figure: why should five <xsl:result> statements be such a big deal? A hacky suggestion: an RTF could be constructed, where the results would be (ordered) immediate children of the root. This wouldn't be necessaru if tuples existed in the language. Most annoyingly, the case where one value is being returned isn't very elegant. I'm not sure if it's possible to seriously suggest returning each result without a parent node connecting them (like an XML fragment). Dave 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