You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xalan.apache.org by Henry Zongaro <zo...@ca.ibm.com> on 2004/01/08 16:38:20 UTC

JSR 206 (JAXP 1.3) Public Draft

Hello,

     A public review draft of JAXP 1.3 [1] was recently issued under the 
Java Community Process:  JSR 206.  The public review period ends January 
15.  I would encourage users and developers of Xalan-Java to take a look, 
and submit any comments they might have.

Thanks,

Henry
[1] http://jcp.org/aboutJava/communityprocess/review/jsr206/index.html
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

RE: [xsl] Re: JSR 206 (JAXP 1.3) Public Draft

Posted by Michael Kay <mh...@mhk.me.uk>.
> 
> I think the spec should clearly define the behavior of setURIResolver 
> for both interfaces. IMHO it should work like this:
> 
> - if a resolver is set on the factory it is used for 
> xsl:import/include
> - if a resolver is *not* set on the factory the base URI of 
> the XSL is 
> used to resolve the import/include'd XSL relative to the base URI
> - if a resolver is set on the transformer it is used for document()
> - if a resolver is *not* set on the transformer the base URI 
> of the XSL 
> is used to resolve a relative XML
> 

The other thing that the old spec didn't make clear (I haven't checked
the revision) is whether the transformer uses the URIResolver that was
set in the TransformerFactory at the time the Templates is created, or
the one that is set at the time the Transformer is created.

It's probably rather late in the day to be fixing this for XSLT 1.0, and
JAXP needs more work done on it for XSLT 2.0...

Michael Kay


Re: JSR 206 (JAXP 1.3) Public Draft

Posted by Robert Koberg <ro...@koberg.com>.
Henry Zongaro wrote:

> Hello,
> 
>      A public review draft of JAXP 1.3 [1] was recently issued under the 
> Java Community Process:  JSR 206.  The public review period ends January 
> 15.  I would encourage users and developers of Xalan-Java to take a look, 
> and submit any comments they might have.
> 
> Thanks,
> 
> Henry
> [1] http://jcp.org/aboutJava/communityprocess/review/jsr206/index.html

I have used URIResolvers quite a bit in my projects. I have also tried 
to make my code use all the popular jaxp XSL processors. It has been a 
sad experience because the way they are implemented differ from each 
other (even xalan and XSLTC differ, as I have explained on the lists 
here in the past). This new spec does little to clarify things.

Under Transformer.getURIResolver() it says:

"Get an object that will be used to resolve URIs used in document(), etc."

What does 'etc' mean?

Under Transformer.setURIResolver it says:

"If the resolver argument is null, the URIResolver value will be 
cleared, and the default behavior will be used."

Does this mean that if a URIResolver was set on the TransformerFactory, 
it would fallback to it? Does this mean you need to call the set method 
with a null to get the default (factory's resolver)?

In the TransformerFactory.getURIResolver it says:

"Get the object that is used by default during the transformation to 
resolve URIs used in document(), xsl:import, or xsl:include."

So if you get your Transformer from a TransformerFactory which one 
resolves xsl:include/import (confused over the use of 'etc' above))?

In the TransformerFactory.setURIResolver it says:

"Set an object that is used by default during the transformation to 
resolve URIs used in xsl:import, or xsl:include."

This makes no mention of document() as mentioned in 
TransformerFactory.getURIResolver.

I think the spec should clearly define the behavior of setURIResolver 
for both interfaces. IMHO it should work like this:

- if a resolver is set on the factory it is used for xsl:import/include
- if a resolver is *not* set on the factory the base URI of the XSL is 
used to resolve the import/include'd XSL relative to the base URI
- if a resolver is set on the transformer it is used for document()
- if a resolver is *not* set on the transformer the base URI of the XSL 
is used to resolve a relative XML

what do you think?

best,
-Rob




> ------------------------------------------------------------------
> Henry Zongaro      Xalan development
> IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
> mailto:zongaro@ca.ibm.com
> 



Re: JSR 206 (JAXP 1.3) Public Draft

Posted by Robert Koberg <ro...@koberg.com>.
Henry Zongaro wrote:

> Hello,
> 
>      A public review draft of JAXP 1.3 [1] was recently issued under the 
> Java Community Process:  JSR 206.  The public review period ends January 
> 15.  I would encourage users and developers of Xalan-Java to take a look, 
> and submit any comments they might have.
> 
> Thanks,
> 
> Henry
> [1] http://jcp.org/aboutJava/communityprocess/review/jsr206/index.html

I have used URIResolvers quite a bit in my projects. I have also tried 
to make my code use all the popular jaxp XSL processors. It has been a 
sad experience because the way they are implemented differ from each 
other (even xalan and XSLTC differ, as I have explained on the lists 
here in the past). This new spec does little to clarify things.

Under Transformer.getURIResolver() it says:

"Get an object that will be used to resolve URIs used in document(), etc."

What does 'etc' mean?

Under Transformer.setURIResolver it says:

"If the resolver argument is null, the URIResolver value will be 
cleared, and the default behavior will be used."

Does this mean that if a URIResolver was set on the TransformerFactory, 
it would fallback to it? Does this mean you need to call the set method 
with a null to get the default (factory's resolver)?

In the TransformerFactory.getURIResolver it says:

"Get the object that is used by default during the transformation to 
resolve URIs used in document(), xsl:import, or xsl:include."

So if you get your Transformer from a TransformerFactory which one 
resolves xsl:include/import (confused over the use of 'etc' above))?

In the TransformerFactory.setURIResolver it says:

"Set an object that is used by default during the transformation to 
resolve URIs used in xsl:import, or xsl:include."

This makes no mention of document() as mentioned in 
TransformerFactory.getURIResolver.

I think the spec should clearly define the behavior of setURIResolver 
for both interfaces. IMHO it should work like this:

- if a resolver is set on the factory it is used for xsl:import/include
- if a resolver is *not* set on the factory the base URI of the XSL is 
used to resolve the import/include'd XSL relative to the base URI
- if a resolver is set on the transformer it is used for document()
- if a resolver is *not* set on the transformer the base URI of the XSL 
is used to resolve a relative XML

what do you think?

best,
-Rob




> ------------------------------------------------------------------
> Henry Zongaro      Xalan development
> IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
> mailto:zongaro@ca.ibm.com
>