Community
Participate
Working Groups
Build Identifier: I20100608-0911 (Version 3.6.0) I reported this issue in the forums (http://www.eclipse.org/forums/index.php?t=tree&th=172922&), and was asked to create a defect report. I believe I've come across a bug in how namespace prefixes are handled during deserialization of an xml document. The issue seems to be with a specific scenario of prefixes being overridden in child elements where the child element is an xsd:any (deserialized as AnyType). I have a scenario where 'firstElement' and 'secondElement' are mapped in ecore, and 'secondElement' is allowed to have xsd:any content. So, in the sample below, 'thirdElement' and its child are deserialized as AnyType. -------- Sample 1: -------- <a:firstElement xmlns:a="http://www.example.org/sandbox" xmlns:c="http://b"> <a:secondElement> <b:thirdElement xmlns:b="http://b" xmlns:c="http://c"> <c:fourthElement/> </b:thirdElement> </a:secondElement> </a:firstElement> When this is deserialized as an EMF resource and subsequently serialized, I get back something like this: <a:firstElement xmlns:a="http://www.example.org/sandbox" xmlns:c="http://b"> <a:secondElement> <c:thirdElement xmlns:b="http://b" xmlns:c="http://c"> <c:fourthElement/> </c:thirdElement> </a:secondElement> </a:firstElement> The output is different from the input: difference being, 'thirdElement' now has a prefix of 'c' and none of the namespace-prefix declarations have changed. -------- Sample 2: -------- Interestingly, if my original xml document was <a:firstElement xmlns:a="http://www.example.org/sandbox" xmlns:c="http://b"> <a:secondElement xmlns:b="http://b" xmlns:c="http://c"> <b:thirdElement> <c:fourthElement/> </b:thirdElement> </a:secondElement> </a:firstElement> I get back something like this after deserializing & serializing: <a:firstElement xmlns:a="http://www.example.org/sandbox" xmlns:c="http://b" xmlns:b="http://b" xmlns:c_1="http://c"> <a:secondElement> <c:thirdElement> <c_1:fourthElement/> </c:thirdElement> </a:secondElement> </a:firstElement> Even though the changes in the prefixes are not to my liking (I would have preferred that the prefixes could have been preserved and I dont see why not. But that is a different topic.), the output is the same as the input, and this is fine. The difference between samples 1 and 2 is that in the former case, the namespace-prefix overriding happens in an xsd:any element. I hope my description is clear. Reproducible: Always Steps to Reproduce: 1. Unzip the attached zip file to some location. 2. Open 'emfbug/workspace' folder as your workspace. You will notice a few emf projects. 3. Run the launch configuration "Sandbox Application". 4. This will launch another eclipse instance. It should open an existing workspace 'emfbug/runtime-EclipseApplication' which contains a 'test' project. 5.1 Make a copy of test1.sandbox, and then open the file with "Sandbox Model Editor". 5.2 Make some change so that the editor is dirty, and then save the file. 5.3 Compare the file before and after the change (like test1.sandbox and test1-result-before-fix.sandbox). Note that the namespace for 'thirdElement' is incorrect. I have also included a fix that I am using currently. The fix is not ideal, but it works. Perform the following steps to apply the change and retest. 6. Open SandboxResourceImpl.java in your base eclipse IDE. Uncomment code that is commented out in createXMLHelper(). 7.1 Make a copy of test1.sandbox, and then open the file with "Sandbox Model Editor". 7.2 Make some change so that the editor is dirty, and then save the file. 7.3 Compare the file before and after the change (like test1.sandbox and test1-result-after-fix.sandbox). Note that there is no difference. Phew!
Created attachment 180003 [details] Test project, including potential solution
Note that I've made several attempts to deal with this issue, but this touches on very scary fragile code that easily breaks when changed. There are so many darned maps for keeping track of prefixes and URIs. I don't anticipate being able to fix this in the foreseeable future.
This corner case won't be fixed. It's too likely to break some existing use case.