GXT's XmlReader sits on top of the build in XML parser that exists in the browser itself. It uses the com.google.gwt.xml.XML module in GWT to gain relatively consistent access to the XML nodes across all browsers, rather than building its own XML parser. By using the built-in implementation in the browser, GXT gets access to the native parser - and it turns out browsers are very good at parsing XML, since that's what they do all day, loading webpages.
Then, GXT has its own query engine to find nodes, in a query language that uses a combination of XPath and CSS3. This mix is to allow it to work well for looking for nodes in the html itself, as well as looking for nodes in xml documents. This is designed to be consisten
However, browsers have inconsistent support (I'm looking at you, IE) for namespaces, and so the XML module in GWT doesn't know how to talk about namespaces, and the DomQuery engine doesnt really either. Additionally, the : operator, which in XML means 'namespace', is used to mean 'psuedo-selector' in CSS, so the query language would be a little vague if it supported this directly: The string foo:bar could either mean "All elements with name foo that match psuedo-selector bar", or "All elements with name bar in the namespace foo".
So enough with the problem: whats the solution? At present, there isn't a good one for namespaced elements in IE6/IE7/IE8 - one part inconsistencies in the browsers and one part lack of ugly workaround in GXT means that you can't read out the elements directly. For all other browsers, to select elements like namespace:eltname, just use @PropertyName("eltname").
One other note: Due to the fact that attributes don't have psuedo-selectors, you can
select them - @PropertyName("namespace:attrname") will correctly read out values in the attribute in <element namespace:attrname="value">.