I am building an end to end XML application that ingests different types of XML feeds and using Saxon for the transformation and XSD validation. Each feed has their own dedicated XSLT templates and XSDs, but do share a few common templates.

I am wondering if there is a way to have a primary XSLT template that will determine the feed type and only load the necessary stylesheets for that feed? Or do I need to make that determination before the transformation and keep each transformation pipeline separate?

I am trying to avoid loading unnecessary stylesheets.

I just found this post on the www.dpawson.co.uk faq pages which
seems to address my question. I assume this logic still stands. So,
I will want to determine the feed type first, then apply the
feed specific stylesheets (that import any common modules), right?
I was hoping to keep this logic within the transformation process,
but it seems like I cannot.

From http://www.dpawson.co.uk/xsl/sect1/N169.html:

> It seems that there is no way to dynamically import or include another
> stylesheet, unless one writes the calling stylesheet at runtime.
Correct, xsl:include and xsl:import are compile-time facilities.
> More concretely, I am trying to create a sheet that uses a default
> stylesheet for a portion of an HTML document, but I want that
> portion to be able to be replaced by a user simply specifying
> an alternate stylesheet source in the source XML of the translation.
The desire for run-time xsl:import is voiced quite often, and for once it's nice to hear exactly why you want it, so that I can tell you why you don't!
Instead of A conditionally importing stylesheet B1, B2, or B3 each of which replaces part of A, the user should select stylesheet B1, B2, or B3, each of which imports the fixed stylesheet A and replaces or overrides parts of it. The special-case stylesheet should import the general-case stylesheet, not the other way around.

It depends a little bit what technology you are using to control the pipeline, e.g. whether it's something like XProc or Orbeon, or whether it's hand-coded Java; and if it's Java, what APIs to Saxon you are using.

Generally, I would suggest building the document as a Saxon tree, then inspecting it using XPath to determine the "feed type", then running the appropriate transformation using the already-built document. If you don't mind using Saxon-specific interfaces, I think you'll find s9api works well for this kind of application.

__________________
Michael Kay
http://www.saxonica.com/
Author, XSLT 2.0 and XPath 2.0 Programmer\'s Reference

Thank you for the guidance. We will likely be using Java, but I haven't looked into XProc or Orbeon, which I will now be doing shortly.

Does the latest release of Saxon support xproc?

No, but the latest XProc processors support Saxon ;-)

XProc is a fairly new kid on the block, the most mature processor is probably Calabash from Norm Walsh. Orbeon has been around much longer, and has many more tools, but currently supports its own pipeline language rather than XProc. It works with Saxon too.

__________________
Michael Kay
http://www.saxonica.com/
Author, XSLT 2.0 and XPath 2.0 Programmer\'s Reference