result document needs to conform wrt namespaces

NEW
Unassigned

Status

()

P5
normal
18 years ago
10 years ago

People

(Reporter: axel, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

18 years ago
http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#Namespaces-Considerations
says that dom doesn't care about xmlns attributes being right. So while 
generating the output document, we need to add those attributes.

Axel
(Reporter)

Updated

17 years ago
Priority: -- → P5
(Reporter)

Comment 1

16 years ago
We should really do this, for both standalone and module.
Extra care should be taken for xsl:element and xsl:attribute, as those can
generate prefix/namespace combos that don't exist, so they need an extra xmlns.
Carefully chosen to not conflict, of course.

Module should have this for stuff like DOM XPath on the result, the nodes should
be good namespace resolvers.
Just checked the xalan code and it does *not* copy over all namespace-nodes from
the source-document when <xsl:copy> is used to copy an element.

Comment 3

12 years ago
The default in XSLT 2.0 is for <xsl:copy> to copy the namespace nodes, subject to being overridden by its copy-namespaces attribute's value.

http://www.w3.org/TR/xslt20/#element-copy
http://www.w3.org/TR/xslt20/#namespace-fixup

Comment 4

12 years ago
I have a simple case here where I have an identity transformation and when I apply it to XML with 'xmlns...' attributes (defining both default and prefixed namespaces), those don't copy over. I've implemented a ugly, DOM-based hack, but its not fast.

There are 2 areas where I think this is going to be a problem going forward:

1. As more and more 'mashups' are done between various XML data sources on the Web, folks are going to have to qualify their XML with namespaces. Trying to use XSLT to perform transformations on that data and keep the namespace information intact is impossible with this bug.

2. Another (admittedly less common) case is XSLTing an XSLT. The resultant XSLT is missing its namespace information and is therefore useless.

Any thoughts from anyone here on these thoughts and the status/priority of this bug?

Cheers,

- Bill
I don't really see 1 as being a big problem in most cases. Note that all nodes will have the right namespace even though the xmlns attributes are missing. Also note that once you serialize the document it will get appropriate xmlns attributes inserted.

2 is a problem though, but I don't think it's a very common usecase.

The main problem with this bug though is fixing it without causing big performance regressions for *all* transforms. For this reason this specific bug has not been solved by any xslt processor I've seen. It has been fixed in some edgecases, but the general problem is there in most, if not all, xslt processors.

Comment 6

12 years ago
Jonas -

Fair enough. Disappointing, but I don't understand the C/C++ or the design of Transformiix or the 'namespace propagation' issue well enough to argue ;-).

Thanks for the tip that the namespace information is indeed preserved in the DOM. I assume taking the result XML and then serializing and then parsing it should 'do the right thing'? It might be faster than my DOM-based hack.

Cheers,

- Bill
Yes, roundtripping through serialization will work fine
(In reply to comment #4)
> I have a simple case here where I have an identity transformation and when I
> apply it to XML with 'xmlns...' attributes (defining both default and prefixed
> namespaces), those don't copy over.

xmlns attributes are ignored by XPath (see last line of http://www.w3.org/TR/xpath#attribute-nodes). XPath namespace nodes do have an equivalent in the DOM (see http://www.w3.org/TR/DOM-Level-3-XPath/xpath.html#NamespaceNodes), but I personally think we should not be adding those, it'll just be a performance hit for little benefit.

> 1. As more and more 'mashups' are done between various XML data sources on the
> Web, folks are going to have to qualify their XML with namespaces. Trying to
> use XSLT to perform transformations on that data and keep the namespace
> information intact is impossible with this bug.

The absence of xmlns attributes is only important if they are used for things other than the DOM objects (like for parsing attribute values). The DOM itself doesn't care about xmlns attributes so the result is perfectly usable.

> 2. Another (admittedly less common) case is XSLTing an XSLT. The resultant XSLT
> is missing its namespace information and is therefore useless.

Serialization will only work for this if all namespaces used in the XSLT are also used in the DOM.

One thing we could do is add an extension function that returns a nodeset with all the attributes of a node (including xmlns attributes), which would also be useful for bug 175946. Alternatively a function that gives just the xmlns attributes, but that seems less useful to me.
Assignee: keith → xslt
Assignee: xslt → nobody
QA Contact: keith → xslt
You need to log in before you can comment on or make changes to this bug.