assign virtual URIs to generated stylesheets and import them later in other stylesheets

[mkraetke]

Disclaimer: This is a very specific feature request for a use case that most XProc users will probably never face in their lifetime. So I would consider this feature as optional to the XProc standard.

We often generate XSLTs with <p:xslt> from an XML configuration document that is later applied to another XML file. However, sometimes we also want to have one XML configuration that imports another, like in the example below:

<set xmlns="http://transpect.io/xml2tex">

  <import href="../../common-tex/xml2tex/latex.conf.xml"/>

  <ns prefix="dbk" uri="http://docbook.org/ns/docbook"/>

  <template context="dbk:dedication">
    <rule name="dedication" type="cmd" break-after="1" break-before="1">
      <param/>
    </rule>
  </template>

</set>

When we generate an XSLT from the XML configuration and its imports, we merge them together in one XSLT document. In the XSLT, the <xml2tex:template> elements is transformed to <xsl:template>. If in the imported XML document there is also a template that matches dbk:dedication, then you have to make sure that the imported template has a lower priority. Currently we do this by adding priority values for each template. However, this makes it more difficult to overwrite specific templates. Additionally, the user may not be aware of the priorities assigned in the background and may wonder why a template does not match.

So it would be nice to mimic the xsl:import feature with the XML configuration shown above. In XProc, we could achieve this by assigning a canonical URI to a document generated with <p:xslt>. Later, we could import the generated XSLT via its canonical URI within another generated stylesheet with xsl:import.

I look forward to your opinion on this.

Best, Martin

[ndw]

I think this would be a good idea. I think you can do this with my 1.0 implementation.

The tricky part is that lots of steps don't change the base URI of the document as it passes through them, so there needs to be some concrete way of identifying which document you mean.

If we imagine an implementation has some sort of document manager, you could have a step, p:cache-document that takes a document and a base URI. It's an error if a document already exists in the cache with that URI.

If a processor implements the p:cache-document step then it assures that whenever a document is retrieved with a URI reference, any cached document is returned preferentially.

Something like that, anyway.

[ndw]

Implementing this in a standard way would require changes to the spec that are out-of-scope for 3.x. I'm going to move this to the vNext repo.