Bug #1592: Namespace handling of output xml documents - Saxon-CE - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #1592

closed

Namespace handling of output xml documents

Added by David Hume over 12 years ago. Updated over 11 years ago.

Status:

Duplicate

Priority:

Normal

Assignee:

Philip Fearon

Sprint/Milestone:

Release 1.1

Start date:

2012-07-19

Due date:

% Done:

Estimated time:

Platforms:

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).

Actions

Copy link

Updated by Philip Fearon over 12 years ago

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.

Actions

Copy link

Updated by Michael Kay over 12 years ago

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.

Actions

Copy link