[#WSTX-135] RepairingNsStreamWriter class adds a new prefix to parent SimpleOutputElement object.

Woodstox

RepairingNsStreamWriter class adds a new prefix to parent SimpleOutputElement object.

Created: 30/Oct/07 01:03 AM Updated: 15/Nov/07 11:35 PM

Component/s:

None

Affects Version/s:

None

Fix Version/s:

None

Time Tracking:

Not Specified

File Attachments:

RepairingNsStreamWriter.java (26 kb)

Patch Submitted:

Yes

Description

« Hide

the code above is expected to give us

<?xml version='1.0' encoding='UTF-8'?>
<wstxns1:rootElement xmlns:wstxns1="urn://namespace1">
<wstxns2:firstChild xmlns:wstxns2="urn://namespace2" />
<wstxns3:secondChild xmlns:wstxns3="urn://namespace2" />
</wstxns1:rootElement>

<?xml version='1.0' encoding='UTF-8'?>
<wstxns1:rootElement xmlns:wstxns1="urn://namespace1" xmlns:wstxns2="urn://namespace2">
<wstxns2:firstChild />
<wstxns2:secondChild />
</wstxns1:rootElement>

But, wstx writer create a document such as

<?xml version='1.0' encoding='UTF-8'?>
<wstxns1:rootElement xmlns:wstxns1="urn://namespace1">
<wstxns2:firstChild xmlns:wstxns2="urn://namespace2" />
<wstxns2:secondChild/>
</wstxns1:rootElement>

which has missing ns prefix delaraction at the element named secondChild.

For respects of readability and document size, it would be better all namespace declaration are located at the root element.
But XMLStreamWriter doesn't know which xml namespace prefix delaration would be used and when it would be.

Anyway, I found a problem in the method, writeStartOrEmpty(String localName, String nsURI) in RepairingNsStreamWriter class.

RepairingNsStreamWriter writes StartElement in this order.
1) add a ns-prefix mapping to current element. (it would be parent element)
2) create child element <-- The subject of writeStartElement.
3) current element = child element
4) set ns-prefix of current element

I changed the orthe this way,
1) create child element with null prefix.
2) current element = child element
3) add a ns-prefix mapping to current element
4 set ns-prefix of current element

see a attached source file.( writeStartOrEmpty(String localName, String nsURI) )

Description

String ns1 = "urn://namespace1"; String ns2 = "urn://namespace2"; writer.writeStartDocument(); writer.writeStartElement(ns1, "rootElement"); writer.writeStartElement(ns2, "firstChild"); writer.writeEndElement(); writer.writeStartElement(ns2, "secondChild"); writer.writeEndElement(); writer.writeEndElement(); writer.writeEndDocument(); writer.close(); the code above is expected to give us <?xml version='1.0' encoding='UTF-8'?> <wstxns1:rootElement xmlns:wstxns1="urn://namespace1"> <wstxns2:firstChild xmlns:wstxns2="urn://namespace2" /> <wstxns3:secondChild xmlns:wstxns3="urn://namespace2" /> </wstxns1:rootElement> or <?xml version='1.0' encoding='UTF-8'?> <wstxns1:rootElement xmlns:wstxns1="urn://namespace1" xmlns:wstxns2="urn://namespace2"> <wstxns2:firstChild /> <wstxns2:secondChild /> </wstxns1:rootElement> But, wstx writer create a document such as <?xml version='1.0' encoding='UTF-8'?> <wstxns1:rootElement xmlns:wstxns1="urn://namespace1"> <wstxns2:firstChild xmlns:wstxns2="urn://namespace2" /> <wstxns2:secondChild/> </wstxns1:rootElement> which has missing ns prefix delaraction at the element named secondChild. For respects of readability and document size, it would be better all namespace declaration are located at the root element. But XMLStreamWriter doesn't know which xml namespace prefix delaration would be used and when it would be. Anyway, I found a problem in the method, writeStartOrEmpty(String localName, String nsURI) in RepairingNsStreamWriter class. RepairingNsStreamWriter writes StartElement in this order. 1) add a ns-prefix mapping to current element. (it would be parent element) 2) create child element <-- The subject of writeStartElement. 3) current element = child element 4) set ns-prefix of current element I changed the orthe this way, 1) create child element with null prefix. 2) current element = child element 3) add a ns-prefix mapping to current element 4 set ns-prefix of current element see a attached source file.( writeStartOrEmpty(String localName, String nsURI) )

Show »

All

Comments

Work Log

Change History

Sort Order:

Ascending order - Click to sort in descending order

[ Permlink | « Hide ]

Tatu Saloranta - 30/Oct/07 01:00 PM

This does indeed look like a bug (assuming output you added is what is produced).

One quick question: which version is this against?

Also, thank you for the patch! That is much appreciated.

[ Permlink | « Hide ]

Tatu Saloranta - 31/Oct/07 12:47 AM

Never mind, seems to be present in trunk and 3.2 at least.

I went ahead and added unit test similar to the one suggested into StaxTest project, compiled and added to Woodstox, to verify the eventual fix. Fix explanation makes sense given the problem.

[ Permlink | « Hide ]

Yoon-Je Choi - 31/Oct/07 09:00 PM

Yes, it is present in 3.2 at least.

Nowdays, I'm working on creating a kind of XML binding.
It generates code which handle marshalling and unmarshalling with stax parser.
It should be capable of handling both byte[] and Node so that I use both RepairingNSStreamWriter (for byte[]) and DOMWrappingWriter.

But now, reparingNS option of DOMWrappingWriter is not available yet.
If reparingNS option of DOMWrappinWriter could be enabled, the XML biding I working on will not concern which object (byte[] or Node) it will handle.
(Because It would handle XML Document with XMLStreamWriter and XMLStreamReader interface.)
Otherwise I cannot use same code for marshaller for byte[] and marshaller for Node.

So, I wonder When would be this function, DOMWrappingWriter capable of reparingNS, released.
If it's not scheduled or so, I should add a sort of namespace context function to my engine.
(or as I mentioned, I may implement Node marshaller without XMLStreamWriter interface).

Anyway, thank you for fixing my issues.

[ Permlink | « Hide ]

Tatu Saloranta - 01/Nov/07 12:27 PM

Cool, sounds like an interesting and useful tool/library that you are working on.
Like I said, I should be able to fix the problem as per your suggestion pretty soon now (hopefully over the weekend). And since there have been a few other fixes submitted, should release 3.2.3 as well (something I hadn't planned to do, but bugs need to be squashed ASAP).

As to DOM writer: unfortunately time I can spend on woodstox is somewhat limited now. Also, finishing that part up was not very high on my list, so I wasn't expecting it to be done very soon.
But if you want it to get done, there are 2 things that would help:

(a) If you can file another issue (new feature or improvement) in Jira for implementing namespace-repairing mode for DOMWrappingWriter, that would help (and of course you can also vote for it). That way it's easier for me to track what kinds of things users want. I will try to prioritize things so that it's partially based on wishes of users, not just my own preferences.
(b) Alternatively, if you (or any other woodstox user) could contribute an implementation, I would be happy to integrate it in. It should not be very hard to implement, although not trivial either (if it was trivial, I would have finished it right away).

One possibility is that if you do end up writing your own namespace context, perhaps that might help in someone implementing equivalent functionality within Woodstox?

At any rate, thank you for reporting the problems, as well as patience in getting them resolved. I really appreciate it, since DOM compatibility part was not heavily used or tested earlier.

[ Permlink | « Hide ]

Tatu Saloranta - 02/Nov/07 01:04 AM

Fixed along the lines proposed (did reorder things a bit to remove some duplicate code as well).
Applied to 3.2 branch as well as trunk.

[ Permlink | « Hide ]

Tatu Saloranta - 15/Nov/07 11:35 PM

Fix included in 3.2.3 release