[Mono-list] xml bug?
Tue, 20 Jan 2004 15:54:52 +0900
> We should have rejected your XML, as you are trying to add more than one
> top-level element (document element) to your document. The fact that we
> don't do so is a bug.
Thanks for the notice. I remember that I added and reverted that check
because once it was not done by .NET Framework 1.1 beta. Now it looks
checked again, so I will recover that check again.
> Now, as for the xmlns, xmlns is a special attribute, setting
> the xmlns attribute doesn't really do anything for the infoset, and the
> b2 element is created in the null namespace. This is why the serialiser
> puts the xmlns="" on b2, that is so that b2 is in the namespace it was
> created in.
I think there are two way of thinking about it (because there seems no
description about xmlns handling on W3C DOM Core specification). Well,
a) supply no xmlns for default namespace
This looks more de facto standard way. I wrote similar code with jdk 1.5
and got the same result as MS.NET.
When we don't want to handle namespaces for classical styled xml, this
alternative will provide better solution. Note that JAXP has explicit
on DocumentBuilderFactory, while .NET XmlDocument doesn't have such.
This alternative results in that we can never add nodes in default
namespace as descendants of a node in non-default namespace.
b) supply xmlns=""
As David pointer out, this is consistent with Infoset. Why it is
important? You might understand when you add one line before calling
Console.WriteLine ("namespace URI: " + b2.NamespaceURI);
And what will occur when using this InnerXml string as an input to
Or what will occur when replacing one line:
new XmlNodeReader (doc)
new XmlTextReader (doc.InnerXml)
However, it will break .NET program compatibility.
... Ok, maybe it would be better to choose alternative a) here, since
most of .NET programmer won't expect correct default namespace handling.
I will fix this.