Re: [xsl] Re: namespace values

Subject: Re: [xsl] Re: namespace values
From: cutlass <cutlass@xxxxxxxxxxx>
Date: Tue, 13 Mar 2001 16:23:54 +0000
I admire your work and will certainly be glad to use a library of ***standard*** XSLT templates, implementing the various functions you proposed as part of XSLT.
I also will be glad to contribute to such an effort.

second that !


To summarise -- I am for the functionality, but strongly against changing the language.


a) does XSLT have a core set of functions that satisfies common user requirements (' i want a date', 'i want easy way to group',' i want to encrypt this' ) when building commercial stuff ?

i think the question has to be no, mostly due to using XSLT for things its not been designed for.

if we are replacing some core functions, lets say with XSLT code itself, i think we will have some serious performance problems when doing relatively simple logic.

'i want the log() of a 10 decimal number that happens to be a julian date which is in URLencoded form from an env variable ', but i want it fast...hehe i am certain that JT could do it with an XSLT.

XSLT requires a larger set of core function to be seriously useful; oh well, then we should get these functions as core in the language, or integrate with other languages, hmm i can feel myself changing my mind on <xsl:script/>.....


b) does XSLT require a way of defining functions ?


i think for implementors, this is extremely important, for any portability to exist betwixt XSL parsers, implementators need to take a unified cue on extending their own implementations past XSLT spec, we hope.

as for functions written with XSLT and building up user libraries, yes, but it seems like a short term thing, because EXSLT on purpose is not attempting to deal with issues of larger scope ( distributed processing, remote libraries, secure controls on resources, digital signing, etc )

c) a few more random comments with respect to XSL and SOAP

defining functions in the classic sense, ignores the current challenges of distribution ( think security patches ), controls ( think quota on an ASP ),true OO capabilities ( want to have functions that have some nice inheritance rules like RDF ), and distributed processing ( want to simplify writing distributed applications ). we also want these functions to behave themselves.

this is why i look at dealing with functions with RPC sunglasses on, especially in light of DCOM debacle. we should expect that some solution characteristics of functions to deal with RPC issues also.

here is an example; been developing over the past year a kiosk system;

so without using <xsl:script> or not armed with a library of badly needed functions i set up a SOAP server to act as my 'function' server, ouch i know.

I use a SOAP server that serves up functions to a system of dumb kiosks ( no local processing capability, except IE MSXML3), passing the results of the SOAP call as an xsl:param to a local XSLT and is then processed on the client side browser, in a situation that just so happens to require a central repository of functions. this works kinda well, in fact things are quite smooth and decoupled ( except that my dumb client is too smart, i would use linux for a kiosk OS most days of the week, but there are some advantages with MSXML3 ).

since SOAP server is dealing nicely with the more procedural technologies ( with implementations being created for a whole slew of servers and clients )why not reuse the idiom within XSL, and have a SOAP client built into XSL parser, let SOAP deal with digital signing, transactional payloads, encryption.

SOAP+XSL could be a 'killer' combination if all in one package. and of course we can build SOAP messages because they are xml, a little suger might be nice to make it super easy.

this combination could be that nice bit of indirection that we are all looking for <xsl:script> to have also.


cheers, jim fuller













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



Current Thread