Well, I for one like the idea. The whole security implication of having the parameters blindly showing up in the default namespace always bothered me.Its on a par with certain well known companies database binding layers automagically converting input parameters into database bindings...
I'm not sure I follow the whole logic of needing to parse the stylesheets to divine a namespace. Simply declare that you WILL use namespace X, and leave it at that. If the stylesheet author chooses not to define the proper namespace, then his input parameters disappear into a black hole. Its up to him to make sure he gets them. Thus there is no need to parse anything, just document what the namespace is (the example below seemed fine, just map cgi: prefix to "http://www.axkit.org/2003/XSL/cgi-parameters"; and everyone simple has to put that in their stylesheets (or not as they wish). On Friday 28 February 2003 05:22 am, Robin Berjon wrote: > Nik Clayton wrote: > > Are you sure? Every XSLT reference I've seen (Michael Kay's 'XSLT > > Second Edition', and numerous web-based references) define the 'name' > > value as being a QName, and then go on to define a QName as having an > > optional namespace prefix. > > Yes, params have QNames and thus can indeed have namespaces. Note though > that they work differently from other QNames in that they are not covered > by the default namespace (as attributes). There is a bug in some old > libxslts that doesn't know about that. > > > So something like this: > > > > <?xml version="1.0" encoding="ISO-8859-1" ?> > > > > <xsl:stylesheet > > xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; > > xmlns:cgi="http://www.axkit.org/2003/XSL/cgi-parameters"; > > version="1.0"> > > > > <xsl:param name="cgi:bugid" select="''"/> > > > > <!-- use $cgi:bugid to refer to the contents of the 'bugid' > > variable passed in using CGI --> > > </xsl:stylesheet> > > > > These don't have to be available by default (to avoid the processing > > overhead). The AxKit/XSLT engine can enable them if the stylesheet > > references the appropriate namespace[1]. > > > > [1] He says, waving his hands in the air hoping no one will ask 'How?'. . > > . > > We normally know enough about the pipeline when in the Plugin phase to do > that. We know about the stylesheets so we can parse them and find namespace > declarations (this would have to be cached though). Based on that we could > indeed activate some parameters. > > I must say I like the idea because I always found it painful, especially in > development, that CGI params were enforced unto me and occasionally clashed > with my own variables. I made a plugin[0] to counter that and it's part of > my default set up. > > Your proposal does have a few problems though (that can be overcome): > - it's costly, so the results of looking inside the stylesheets will > have to be cached > - I don't know if/how the programmatic interface to LibXSLT (and > Sablotron, a patch would have to cover both) allow this > - it's not backward compatible > - someone has to code it (go Nik, go!) > - based on previous conversations surrounding this topic, we're probably > the only two people that would prefer it this way ;) > > > [0]http://search.cpan.org/author/RBERJON/AxKit-Plugin-DisableXSLTParams-0.0 >1/DisableXSLTParams.pm -- Tod Harter Giant Electronic Brain --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
