Inheriting resolver objects to secondary inputs (doc(), collection(), xsl:import, …)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Inheriting resolver objects to secondary inputs (doc(), collection(), xsl:import, …)

Christian Roth-4
Hi,

my problem to solve (Saxon 9 Java):

I have an application that uses differently configured catalog and entity/URI resolvers (i.e. object instances) for parsing the XML to be transformed with XSLT processors. The important thing here is that within the same application, transformations need to be performed by different XSLT processors (Xalan, Saxon6, Saxon 9) concurrently, and for each of these concurrent transformations, a different catalog and entity/URI resolver configuration needs to be used. However, within each single one of these transformations, root XML source and XSLT files as well as any secondary sources that might need to be parsed as a result of e.g. xsl:include, xsl:import, doc(), collection() etc. should share (inherit) the same XML parsing and catalog configuration.

What is the way to do this, or more specifically: What APIs should I use to have the root XML document parser configuration of a transform essentially "inherited" to any of its child XML parser instances it might need to spawn (xsl:include, xsl:import, doc(), collection(), a DOCTYPE)?

It is my understanding that I cannot set a JAXP XML parser factory class, as that would be (1) global to all threads requesting an XML parser, and (2) would not have individual configurability within single transforms as it's a CLASS that is specified, not a specific INSTANCE.

Is there a way to specify for a transform something like (conceptual) a configured XML parser INSTANCE that is used for all secondary XML parsing tasks during that transformation?

Or is this all simpler than it appears? :-)

Thanks for any tips and ideas on how to do this.

Regards
Christian
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 
Reply | Threaded
Open this post in threaded view
|

Re: Inheriting resolver objects to secondary inputs (doc(), collection(), xsl:import, …)

Michael Kay
I’m having a little difficulty understanding the details of this, but I’ll try….

I think you probably want to control the allocation of XMLReader instances within your application rather than leaving it to Saxon. That means supplying a SAXSource object with a contained XMLReader. You can generally do this from within the URIResolver.

In JAXP the URIResolver is excessively global. The s9api interface gives you more control, e.g. you can allocate a URIResolver for a specific XSLT compilation, which will be called to resolve xsl:include and xsl:import.

So basically, I think if you write a URIResolver class that responds to a resolve() requests by returning a SAXSource containing an XMLReader that you configure as you wish, then you can do what you need to.

Michael Kay
Saxonica

> On 14 May 2015, at 01:08, Christian Roth <[hidden email]> wrote:
>
> Hi,
>
> my problem to solve (Saxon 9 Java):
>
> I have an application that uses differently configured catalog and entity/URI resolvers (i.e. object instances) for parsing the XML to be transformed with XSLT processors. The important thing here is that within the same application, transformations need to be performed by different XSLT processors (Xalan, Saxon6, Saxon 9) concurrently, and for each of these concurrent transformations, a different catalog and entity/URI resolver configuration needs to be used. However, within each single one of these transformations, root XML source and XSLT files as well as any secondary sources that might need to be parsed as a result of e.g. xsl:include, xsl:import, doc(), collection() etc. should share (inherit) the same XML parsing and catalog configuration.
>
> What is the way to do this, or more specifically: What APIs should I use to have the root XML document parser configuration of a transform essentially "inherited" to any of its child XML parser instances it might need to spawn (xsl:include, xsl:import, doc(), collection(), a DOCTYPE)?
>
> It is my understanding that I cannot set a JAXP XML parser factory class, as that would be (1) global to all threads requesting an XML parser, and (2) would not have individual configurability within single transforms as it's a CLASS that is specified, not a specific INSTANCE.
>
> Is there a way to specify for a transform something like (conceptual) a configured XML parser INSTANCE that is used for all secondary XML parsing tasks during that transformation?
>
> Or is this all simpler than it appears? :-)
>
> Thanks for any tips and ideas on how to do this.
>
> Regards
> Christian
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help 


------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help