I'm using Schematron to validate instance XML documents inside a custom schema aware XML editor (note that Schematron validation is just an XSLT transformation). The instance may contain elements with a path in it's value (a simplified XPath expression). An example of such a path would be:
/p:root/p:level-one/r:level-two/r:level-two-leaf
where both prefixes (p and r) are bound to a namespace defined in the instance document. My Schematron validates such paths by ensuring that an element to which the path points actually exists in the instance document. It relies on EXSLT to do this (I am forced to use XSLT1.0), more precisely on dyn:evaluate()
in order to evaluate the element's text value, which as you can see is basically an XPath expression. It works like a charm.
But there is one problem, a huge one actually. The call to dyn:evaluate()
is executed from a Schematron XSLT which evaluates the XPath expression in it's own namespace context. This means that in order for this to work properly both the instance document and the Schematron XSLT must use exactly the same prefix → namespace binding. I cannot force a user to use the same prefixes for the same namespaces which are specified in my schema...that would be a silly requirement (it is however ensured that at least the same namespaces will be used in both). Schematron is always generated before instance validation takes place but this is done only once for performance reasons. The only option I have is to somehow pre-process the paths from the instance and do some sort of translation from “instance paths” to “XSLT paths”. I'm new to XSLT and have no idea how I could possibly achieve this.
How would I translate such text values into what's required by the XSLT's namespace context? Is this even possible? I'm currently thinking about in memory fixes of the XSLT (all this is done within Java) before each validation call – renaming prefixes so that they match the instances binding or injecting new namespace attributes – but this could lead to prefix name clashes and I'm not sure about how it would impact validation performance. I'm open to any suggestion, since I am assuming this is something other people must have come across too (while using Schematron or dyn:evaluate()
).
Edit: the clarification of what I'm trying to do follows from here on.
I have an XML instance file which is being edited by a user in the editor. An example of such a file would be:
<?xml version="1.0" encoding="utf-8"?>
<config xmlns="http://example.com/ns/config"
xmlns:cfg="http://example.com/ns/config"
xmlns:ns1="http://example.com/ns/custom-01"
xmlns:ns2="http://example.com/ns/custom-02">
<ns1:some-element>/cfg:config/ns1:other-element/ns2:nested-element</ns1:some-element>
<ns1:other-element>
<ns2:nested-element>some value</ns2:nested-element>
</ns1:other-element>
</config>
Such a document then goes through schematron validation which is basically an XSLT transformation. It will only be declared valid if the path in ns1:some-element
refers to an existing element within the same document (the example above is therefore valid).
The schematron XSLT looks something like this (note that is has been greatly simplified):
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<!--This XSLT was automatically generated from a Schematron schema.-->
<xsl:stylesheet xmlns:iso="http://purl.oclc.org/dsdl/schematron"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:dyn="http://exslt.org/dynamic"
xmlns:exsl="http://exslt.org/common"
xmlns:sch="http://www.ascc.net/xml/schematron"
xmlns:cfg="http://example.com/ns/config"
xmlns:cust1="http://example.com/ns/custom-01"
xmlns:cust2="http://example.com/ns/custom-02"
extension-element-prefixes="dyn exsl"
version="1.0">
<!-- other templates -->
<xsl:template match="/cfg:config/cust1:some-element">
<xsl:choose>
<xsl:when test="dyn:evaluate(.)">
<!-- do stuff -->
<xsl:when>
</xsl:choose>
</xsl:template>
<!-- other templates -->
</xsl:stylesheet>
I'm sure this explains the problem. The call to dyn:evaluate(.)
will try to evaluate the /cfg:config/ns1:other-element/ns2:nested-element
XPath expression, which uses unbound prefixes from the transformation's prespective (and as such always evaluates to false).
The question was and still is: how can I translate these XPath expressions so that they actually have meaning within the transformation?