jon gold wrote:
>> Depending on the schema, that seems like a correct behavior to me. It
>> really depends on how "bar" is declared.
>>
>
> bar is declared in the same schema as foo. ie, i have
>
> <schema targetNamespace="http://somens"
> xmlns:this="http://somens" ...>
>
> <complexType name="BarType">...</
>
> <complexType name="FooType">
> <sequence>
> <element name="bar" type="this:BarType"/>
> ...
> </
> </
>
> <element name="foo" type="this:FooType"/>
> </
If the schema has @elementFormDefault="qualified", the following would
be valid:
<foo xmlns="
http://somens">
<bar>...</bar>
...
</foo>
but the following won't:
<bar xmlns="">...</bar>
If it doesn't have that attribute, it's the other way around.
This is one of the million reasons I hate W3C XML Schema.
>> The change you made was a very significant change --- it changed the
>> namespace URI of the bar element. So if one was valid, the other is
>> definitely invalid.
>>
>
> that's why i was surprised. the change (not using createElementNS) gives
> me a bar which is not in any namespace, which marshals okay, but i would
> think *shouldn't*, since the bar i want is in the somens namespace.
Mixing namespace aware DOM nodes (like the one returned from
createElementNS) and pre-namespace DOM nodes (like the one returned from
createElement) is a recipe for a disaster. I saw many nasty issues in
many places because of this. Countless hours have been wasted on this.
This is one of the million reasons I hate W3C DOM API.
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com