> > > Instead of extensions you could use custom URIResolvers to return the > > result > > > from anywhere (or just do something and return succes/fail) to an > > representation > > > usable by a transformation. > > > > That would work, but where I'm heading I essentially want the equivalent of > > a uri-resolver to be coded using XSLT looking not only at the URI but also > > the current context. > > in XSLT 1.0 you can do: > > <xsl:apply-templates > select="document($util_function, $client_site)"/> > > Where you pass the href and base arguments to the resolver. The 2cnd arg being > the context.
Yes, but that still misses the point; you're going from XSLT to Java, what I want to do is go from Java to XSLT to resolve the uri against the context. I want to be able to exploit the rules based style of programming that XSLT allows in order to determine what I want to invoke next in the pipeline... A slightly different issue is that, as it currently sits, you only pass one context to the resolver. Although this could be built up, it would be nice to be able to essentially run a vector of contexts; current request, current session, database connections, JNDI pointers, etc... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
