DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26319>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26319

Namespaced attributes not correctly serialized

           Summary: Namespaced attributes not correctly serialized
           Product: XalanJ2
           Version: CurrentCVS
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: org.apache.xalan.serialize
        AssignedTo: [EMAIL PROTECTED]
        ReportedBy: [EMAIL PROTECTED]


Using a fresh build of Xalan from the CVS trunk as of today. More or less
corresponds to the 2.5.2 release I think.

I run the attached Java test program using JDK 1.3.1 (so as to avoid any
interference from the JAXP impl in JDK 1.4):

$ java -cp ${loc_of_program}:build/xalan.jar:bin/xml-apis.jar:bin/xercesImpl.jar
TryJaxpSerialization

and get the attached output.

The program constructs an in-memory DOM tree with various namespaces, and
attempts to write it out

1. Using the automatic identity transform from Xalan.

2. Using an explicit identity transform with Xalan.

3. Using the serializer package supplied with Xerces.

#1 and #2 come out the same (good!), but have a bug not present in #3:
namespaces do not seem to be interpreted on attributes. On the <bar> element, I
have set the attribute "key" (no prefix defined) with namespace "urn:test3", yet
it is written out with no namespace or prefix information, which is incorrect. I
even set the attr "t4:key" (explicit prefix in the QName) with namespace
"urn:test4"; the prefix is written back out but with no namespace declaration,
again incorrect.

Xerces' serializer gets both cases right: in the first case, by generating a
prefix; in the second, by writing out a declaration for the existing one. Xalan
should do the same.

Note also that the test program does create *elements* with different namespaces
with no colon in the QName (e.g. "baz" in "urn:test2"), and Xalan correctly
serializes them (for the most part - see below). The problem only seems to apply
to attributes.


Possibly related bugs (I am not really sure):

Bug #5779:  "Default identity" transform not generating namespace declarations
Bug #5389:  Prefixed attrib in different namespace from its element bad
Bug #16613: I cannot use dummy transform technique to serialize a document with
namespaces
Bug #26075: non-prefixed attributes should not be in default namespace


Another bug in Xalan's serialization not present in Xerces' serializer: an
element with a null namespace should generate xmlns="" if a default namespace
would otherwise be in effect. Note however that Xerces' serializer seems to do
this only if you use a DOM2 method to create the element; otherwise it seems to
be kept internally with no namespace information (not even that it has none),
which is a little odd.


The DOM 2 Core spec

http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#Namespaces-Considerations

states

"In particular, since the mapping between prefixes and namespace URIs is not
enforced, in general, the resulting document cannot be serialized naively. For
example, applications may have to declare every namespace in use when
serializing a document."

but on the other hand the XSLT spec

http://www.w3.org/TR/xslt#section-XML-Output-Method

states

"[...] the output should be such that if a new tree was constructed by parsing
the wrapper as an XML document as specified in [3 Data Model], and then removing
the document element, making its children instead be children of the root node,
then the new tree would be the same as the result tree, with the following
possible exceptions: [...]  The new tree may contain namespace nodes that were
not present in the result tree. NOTE: An XSLT processor may need to add
namespace declarations in the course of outputting the result tree as XML."

Only JAXP, I think, directly ties an XSLT processor to a DOM input source, which
may be the origin of this kind of problem.

Reply via email to