[XSL-LIST Mailing List Archive Home]
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
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
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