Project

Profile

Help

Bug #1592

closed

Namespace handling of output xml documents

Added by David Hume over 10 years ago. Updated almost 10 years ago.

Status:
Duplicate
Priority:
Normal
Assignee:
Sprint/Milestone:
Start date:
2012-07-19
Due date:
% Done:

0%

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 #1

Updated by Philip Fearon over 10 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 #2

Updated by Michael Kay over 10 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 #3

Updated by O'Neil Delpratt almost 10 years ago

  • Status changed from In Progress to Duplicate

Duplicate of issue #1697

Actions #4

Updated by O'Neil Delpratt almost 10 years ago

  • 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