> to better isolate classloader and the contracts that are exposed by the > block. make development more complicated but forces people to think of > application contracts that can be later reused as global behaviors. > > think of it as a generalization of a collection of interfaces and data > structures that are passed around. like JAXP+Xerces jaxp is public, > xerces should not be, otherwise the public methods of the xerces > classes can be hooked up and later broken if a new implementation of > JAXP comes around.
I posted the text below to the XSL list a few weeks ago (can't find it in the archives). Mike Kay responded saying the JAXP working group was reviewing these issues now and would perhaps come up with clearer specificiations. Cocoon, specifically, might be interested in the Xalan/XSLTC part below. <the post> I want to report my findings with regard to standard implementations of how the method setURIReolver works in the popular Open Source java xsl processors. From what I understand from past discussions is that the spec is not clear on the issue. I was wondering if processor developers could get together and decide either one way to implement the setURIResolver or do it the way Saxon does by doing both (hopefully explained below). According to most API's you can set the URIResolver on the TransformerFactory and on the Transformer. Generally, the resolver set on the TransformerFactory resolves xsl:includes and xsl:imports. If set on the Tranformer it resolves document() function calls. - Saxon allows you to set the resolver on the TransformerFactory to resolve both includes/imports and document(). It also lets you set one for the factory and one for the transformer. When this is done the factory resolves include/import and the transformer resolves document(). This is the best way, IMHO. - jd.xslt only uses the TransformerFactory to be used for xsl:include/xsl:import and document() resolution. Strangely, the standard xalan and it's xsltc implementation do two different things. - standard xalan requires you to use the TransformerFactory for xsl:include and xsl:import and the Transformer for document() - xsltc xalan uses the TransformerFactory for both xsl:include/xsl:import and document() -- not the Transformer for document(), like the standard xalan. Any chance of standardizing on one way? :) </the post> Best, -Rob > > also reduces the potential problems with hot deployment for > classloading dependencies > > -- > Stefano.
