[xsl] Re: xsl:function

Subject: [xsl] Re: xsl:function
From: "Dave Gomboc" <dave@xxxxxxxxxxxxxx>
Date: Wed, 21 Feb 2001 10:25:58 -0700
> 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).


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

Current Thread