> The real solution will be to modify the Processors' process
> interface to pass in a Properties or Hashtable object of parameters.
This is a good approach and I would suggest that these values be available
as XML entities.
Entities are a standard aspect of XML 1.0 and all parser/processors should
have support for them. They can be used in more places than elements. We use
these 'dynamic entities' and they are very useful.
There are still the issues of how much information to make available, etc.
Perhaps we could have an implementation of Entity that is only evaluated
when used. The syntax of the entity value could be some pseudo-scripting
style, similar to other HTML generating server-side systems.
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:firstname.lastname@example.org]
> Sent: Wednesday, December 22, 1999 8:15 AM
> To: email@example.com
> Subject: Re: params to XSL
> Donald Ball wrote:
> > > Short of writing a custom XSL extension, or trying to do
> the string
> > > manipulation in XSL, what other options are open to me?
> > As a workaround, you can add your parameters as an XML
> fragment to the
> > incoming XML document:
> This is the first solution proposed and while somebody might find this
> useful (it keeps on coming up!), I think it's not the right solution.
> > The real solution will be to modify the Processors' process
> interface to
> > pass in a Properties or Hashtable object of parameters. The
> holdups, as I
> > understand, are that not all XSLT processors support
> passing parameters
> > (particularly, the old default, XSL:P). Since Xalan and XT
> both support
> > parameters, I'd say this objection isn't much of an issue anymore.
> > The more important holdup, I guess, is which thingies get
> to be parameters
> > and how do you configure that? The naive approach would be to simply
> > pass all request parameters and values in to the XSLT
> processor. But then
> > someone will want to access cookie values, and session values, and
> > arbitrary HTTP header values, and customer values; how do
> you configure
> > access to each of these? You don't want to always pass in
> _all_ of them or
> > processing each transaction is going to be expensive.
> Right on.
> > My suggestion would be to give the stylesheets access to the request
> > parameters by default, but allow the documents to request
> access to other
> > parameter spaces as well through the use of processing
> instructions (which
> > would, hopefully, optionally migrate to the sitemap with
> all of the other
> > cocoon-specific PIs):
> I were thinking on the same direction while writing the
> sitemap document
> > Normal request parameters would be accessible via:
> > Then the cookie values would be accessible via:
> > And session values via:
> > I can't figure how 'custom' parameters might be included in
> this scheme.
> > Hmm... any thoughts?
> What about
> > The other big objection to this that I can see right now is
> the lack of
> > namespace support in the parameters. That is to say,
> suppose there's a
> > request parameter named 'cookie-foo' and a cookie named
> 'foo'. One of them
> > is going to be inaccessible. We could pick a really obscure
> > seperator string, but that just decreases the chance of
> name collision
> > occuring, doesn't eliminate it. Any ideas on how to address this?
> Forget about PIs and move on to the sitemap. :)
> It's coming...
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> Friedrich Nietzsche
> Come to the first official Apache Software Foundation Conference!
> ------------------------- http://ApacheCon.Com ---------------------