Bug #1592
closed
Namespace handling of output xml documents
Description
Executing a transform like:
<xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:foo="bar"
version="2.0">
<xsl:output method="xml" indent="yes" />
<xsl:template match="/">
<foo:bar foo:me="1">
<testing>
<foo:foo />
</testing>
</foo:bar>
</xsl:template>
</xsl:transform>
with Saxon.serializeToXML(processor.transformToDocument(input))
results in:
<bar xmlns="bar" foo:me="1" xmlns:foo="bar"><testing><foo/></testing></bar>
Which is broken; testing is in the wrong namespace.
Also elements always receive namespaces via "default" declarations, and other namespace declarations are dropped, which makes it challenging to generate xsl stylesheets as a first pass transform since namespaces such as ixsl (used in xpath expressions) are dropped (replaced with a default xmlns binding only on those elements in the ixsl namespace).
- Status changed from New to In Progress
- Assignee set to Philip Fearon
Hi David I will have a look at this and report back.
This XML namespace issue may either occur when writing to the XML DOM (most likely), or when serializing the DOM, or it may even be a combination of the two. There may also be some variance between browsers to consider here. The issue with namespaces used in XPath expressions is difficult because the DOM and serializer won't be aware of the need for these - I'll investigate further.
I fear that we've focussed most of our attention on XML->HTML transformation and XML->XML use cases may have been a little neglected. Whether the problem here is in what we write to the DOM or in the way that the DOM is subsequently serialized, I think that long-term, we shouldn't be dependent on the DOM for a faithful representation of the XDM data model. The Saxon linked tree implementation is present in the product and is used for temporary trees arising during transformation; we should also provide an API allowing it to be used for a final result tree (which can then be used as input to further processing). Apart from anything else, processing a Saxon linked tree is likely to be a lot faster than processing the DOM.
Whether we need to implement a serializer is another question: in the long run, I suspect the answer is yes, just as we probably will also need to provide an API allowing XPath 2.0 expression processing from Javascript.
- Status changed from In Progress to Duplicate
- Sprint/Milestone set to Release 1.1
- Fixed in version set to 1.1
Following the resolution of bug issue #1697 this bug issue is closed.
Please register to edit this issue
Also available in: Atom
PDF
.