Re: [xsl] Re: namespace values

[cutlass <cutlass at secure0 dot com>]

> 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