Community
Participate
Working Groups
Build ID: M20070921-1145 Steps To Reproduce: 1. take XML file <?xml version="1.0" encoding="UTF-8"?> <root> .... <s:xhtml xml:lang="nl" xmlns="http://www.w3.org/1999/xhtml" xmlns:s="http://webplatform.rug.nl/_definition/shared/schemas/shared.xsd"> <div>Over de locaties van de RUG</div> </s:xhtml> .... </root> 2. call om under lying IDOMModel for node <s:xhtml>: String lang = ((Element)getNode()).getAttributeNS("http://www.w3.org/XML/1998/namespace", "lang"); More information: If've traced the problem and it looks like the getNamespaceURI() methor for AttrImpl in org.eclipse.wst.xml.core.internal.document does not return the standard URI for the 'xml:' namespace as by convention of W3C (see: http://www.w3.org/TR/1999/REC-xml-names-19990114/#ns-using) even if the xml document doesn't explicitly name it in its header. I'll provide a proposal for a patch to AttrImpl and IXMLNamespace.
Created attachment 110219 [details] Diff created from eclipse for AttrImpl and IXMLNamespace
Looks like a simple enough fix. Offhand I'd suggest explore fixing this in 3.1, since changing this behavior in 2.x might break some who are accidentally counting on the incorrect behavior. Another question, maybe obvious to others, is how can a client/user tell if the Attr namespece existed explicitly in source, or not. I'm just wondering, you know, for when the Attribute is serialized, etc.
The fix would mean returning the correct namespace instead of null. I think this would not affect the 2.x users, since the current work around is to define explicitly the xml: namespace in the input xml document. This work around is not affected by the fix. We might switch to the 3.0 version anyway. Currently development of our WYSIWYG (html) to XML editor is based on the 3.3 RCP platform.
Valentin, could you review the attached patch? If approved, I'd like to retarget and put it into M2.
The patch is fine in principle, but something else occurs to me. The implementation overall seems to disagree with what the Javadoc says http://java.sun.com/j2se/1.5.0/docs/api/org/w3c/dom/Node.html#getNamespaceURI() That is, this value should not be computed as attribute nodes do not inherit the namespace from the containing element. Save for the fixed URIs, the constant walk up - most time likely all the way up to the root element - is probably also very inefficient. To conform with the spec we should probably save the namespace URI on creation and also take care to compute it when the name changes in the source document. Of course, I may be missing some important reason for why this method was implemented like this. Seems to me we need to think more about this and get good regression tests going.
Created attachment 110681 [details] A patch for 3.1 I could not apply the original patch so I created this one. Mostly identical, except for removing some uneeded public static qualifiers from interface constants (not needed, as they are public and static by default).
(In reply to comment #5) > To conform with the spec we should probably save the namespace URI on creation > and also take care to compute it when the name changes in the source document. I'm not sure about the hierarchical lookup, that might be a bug, but I so recall this area of the spec was not well suited for tools, or editors. For example, we never (or seldom) actually _set_ the namespace, but just discover what happens to be typed there, when someone asks. If we only allowed true DOM operations, the spec would be fine, but since we allow character by character operations, it's gets a little more complicated. So, that's why we compute it ... I'm less sure if the hierarchical lookup is needed and I would have to think deeply about that.
(In reply to comment #7) > (In reply to comment #5) > > > To conform with the spec we should probably save the namespace URI on creation > > and also take care to compute it when the name changes in the source document. > > I'm not sure about the hierarchical lookup, that might be a bug, but I so > recall this area of the spec was not well suited for tools, or editors. For > example, we never (or seldom) actually _set_ the namespace, but just discover > what happens to be typed there, when someone asks. If we only allowed true DOM > operations, the spec would be fine, but since we allow character by character > operations, it's gets a little more complicated. So, that's why we compute it > ... I'm less sure if the hierarchical lookup is needed and I would have to > think deeply about that. > Personally, I'd lean toward following the spec. Especially since this does and can cause interoperability issues when people use the WTP DOM. I suspect this is one of those areas that the WTP DOM fails the W3C Test suite. There are a lot of areas where it fails the W3C Test suite specifically with the way attributes are handled and the assumptions taken.
One more item. There is one namespace prefix that is reserved, and that is the xml prefix. This is outlined in the XML Namespaces 1.0 specification section 3. http://www.w3.org/TR/REC-xml-names/#ns-decl It can be provided by default, which is what should happen in this particular case. The namespace is http://www.w3.org/XML/1998/namespace.
David, Nitin care to have an opinion on the risk of releasing this fix this late in 3.1? Should we perhaps move it to 3.2 and have a "spec conformance" plan item?
I'm pretty sure no one's using it, but the locating of the IXMLNamespace interface in a provisional package gives me additional pause when thinking of adding to it for M7. While an obvious and wanted correction, we'd be breaking the API freeze, plus we don't have any grasp over how much of WTP would be affected. Deferring.
Dave, can you look over the patch w.r.t. comment 9? I'm not sure what you meant by "it can be provided by default", and whether attachment 110681 [details] satisfies that.
We'd also need a JUnit. Any volunteers?
(In reply to comment #12) > Dave, can you look over the patch w.r.t. comment 9? I'm not sure what you > meant by "it can be provided by default", and whether attachment 110681 [details] > satisfies that. > The "xml" prefix extension is a reserved prefix is that is always assigned to the the XML Namespace. http://www.w3.org/XML/1998/namespace Section 3 of the XML Namespace specification defines this requirement: http://www.w3.org/TR/REC-xml-names/#ns-decl So when I say can be defined by default means that if the the "xml" prefix is found, it has to return the namespace defined in the specification. It's an error to override or use the "xml" prefix for anything else. The patch you specified is valid and follows the rules as outlined by the XML Namespace specification. This is a basic xml rule that has to be followed for compatibility and interoperability with other tools and frameworks. (In reply to comment #2) > Looks like a simple enough fix. Offhand I'd suggest explore fixing this in 3.1, > since changing this behavior in 2.x might break some who are accidentally > counting on the incorrect behavior. This is something that needs to be fixed sooner rather than later, because if somebody is depending on the wrong behavior, it is going to cause interoperability issues with other XML related tools that work correctly according to the spec. > > Another question, maybe obvious to others, is how can a client/user tell if the > Attr namespece existed explicitly in source, or not. I'm just wondering, you > know, for when the Attribute is serialized, etc. > See the XML Namespace specification and the XSD Specification on whether attributes are qualified or not. (In reply to comment #13) > We'd also need a JUnit. Any volunteers? > I could take a shot...in fact it might be covered in the W3C test suite already.
Created attachment 131998 [details] Unit Test for proposed Patch With out the patch this test fails, with the patch, the test passes and returns the correct value. Note that the AttrImplTests.java seems to be tagged as binary, it should be tagged as ascii.
Dave, please don't retarget bugs like that, it's up to the assignee and/or component owner. While I appreciate the interoperability concerns, changing it now doesn't leave much time for anyone depending on the broken behavior to recover--and we're not sure how much of WTP itself relies on it.
(In reply to comment #16) > Dave, please don't retarget bugs like that, it's up to the assignee and/or > component owner. While I appreciate the interoperability concerns, changing it > now doesn't leave much time for anyone depending on the broken behavior to > recover--and we're not sure how much of WTP itself relies on it. > Sorry if I did, I didn't mean to retarget it at all.
(In reply to comment #16) > Dave, please don't retarget bugs like that, it's up to the assignee and/or > component owner. While I appreciate the interoperability concerns, changing it > now doesn't leave much time for anyone depending on the broken behavior to > recover--and we're not sure how much of WTP itself relies on it. I'm fine with addressing this in 3.2M1, but the last statement is of concern, especially with the shortened development period planned for 3.2M1. Especially with the possibility of running the w3c dom test suite for Level 1, Level 2, and Level 3 against the current WTP implementation. We are bound to find more of these type of situations.
(In reply to comment #18) > I'm fine with addressing this in 3.2M1, but the last statement is of concern, > especially with the shortened development period planned for 3.2M1. Well, there we have months to make the change and let everyone react--including our own components. I expect Valentin will get the XSD component's usage stabilized with the changes in M1, just as you and Doug will make sure XSL is alright with it.
(In reply to comment #19) > (In reply to comment #18) > > I'm fine with addressing this in 3.2M1, but the last statement is of concern, > > especially with the shortened development period planned for 3.2M1. > > Well, there we have months to make the change and let everyone react--including > our own components. I expect Valentin will get the XSD component's usage > stabilized with the changes in M1, just as you and Doug will make sure XSL is > alright with it. > True...but at the moment, we don't use the feature that is being asked for here, as the namespaces for xslt have to be defined, and it isn't a requirement that xsl or xslt be returned as the prefix. The bug here is that the XML namespace is defined and assigned by default to the xml prefix. So the only way a user is going to run into this bug is if they are trying to retrieve a value for the attribute with that prefix and it hasn't been declared in the xml file itself. This is a very specific bug that will only happen in very specific situations.
Released along with the unit test. I've updated New Help for Old Friends (http://wiki.eclipse.org/New_Help_for_Old_Friends_V), as well.
