[Mono-list] xml bug?

Atsushi Eno atsushi@ximian.com
Tue, 20 Jan 2004 15:54:52 +0900


Hello,

> 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 
setNamespaceAware() setter
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 
InnerXml:

	 Console.WriteLine ("namespace URI: " + b2.NamespaceURI);

And what will occur when using this InnerXml string as an input to 
XslTransform.Transform()?
Or what will occur when replacing one line:

	new XmlNodeReader (doc)

with this?:

	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.

Thanks,
Atsushi Eno