@ Head

Hi Avner,

I wouldn't call it the semantics of LINQ to XML, more the semantics of VB.  VB adds an attribute to the element, which is different than if you were to use the Xelement constructor. It'd be an extra step. When you use an embedded expression, VB then goes about removign the attributes it thinks it might have added ;)

That works in most/some cases but not all, and relies on you defining the namespace via the Imports statement.  That of course only allows one default namespace declaration per .vb code file. If you find yourself actually using default namespaces for example defined inside the XML literals you will get duplication even when using placeholders, e.g:

Dim e2 = <book xmlns="abc"></book>

Dim e1 = <books xmlns="abc"><%= e2 %></books>

That's where my CleanUpNS comes into play ;)

Right. But considering the VB compiler keeps track of what namespaces it adds, and passes them to it's internal clean up namespace method, it should be able to include in that list any defined xmnls attributes in the literals.  So really, code such as :

Dim e2 = <book xmlns="abc"></book>

Dim e1 = <books xmlns="abc"><%= e2 %></books>

should have the second xmlns removed.

:)

Hi Avner and David,

I agree it's nice the way the VB compiler tracks the namespace attributes it adds (those declared as Imports), and then removes those same ones from any elements added as embedded expressions.

The question as Avner says is one of having the developer decide what the XML exactly looks like.

Let's say for example I do specifically add a xmlns, and then add it as an embedded expressions into an element in which I am using Imports. If the xmlns is the same, the VB compiler will remove it, even though it didn't add it, e.g:

Imports <xmlns:a="books.com">

...

Dim book1 = <a:book xmlns:a="books.com">my first book</a:book>

Dim books = <a:books><%= book1 %></a:books>

So the compiler is not *pure* in only removing what it adds. Instead it removes anything that matches what it has added to the root node. This of course makes sense as the added element could be generated anywhere. But it is not a pure fidelity of what the developer wrote. And I'm happy with that as for pure fidelity there is the framework approach that can be used instead.

Which leads us back to the example I gave earlier of default namespaces. The problem is two-fold.  If you declare the Imports at file or project level you are stuck with only one allowed default namespace for the entire code file (or project) What if I want to create two different based files both with default namespaces ?  I can't, and have the same experience of embedded attributes cleaning up the code for me.

Perhaps this removal of namespaces should have been explicit. Maybe it can still be.  If we look at the cases we have:

(a) remove only the xmlns declarations that match those Imported into the parent literal

(b) remove all duplicate namespaces

(c) remove none

So if this was a directive for an embedded expression, it could be expressed as an Enum, RemoveImportsOnly, RemoveAll, RemoveNone, where RemoveImportsOnly would be 0 or the default.

Personally though, I would much rather have the default be to Remove All duplicates, because if I want duplicates I can do that in the framework. What I can't do in Vb9 easily today is remove all duplicates when I'm working with more than one default namespace.

My extension only removes namespace declaration attributes in the element you call it on.  If you are seeing the xmlns being output it is either because the element has a different namespace or the default namespace you are using is not declared at the root level.  The XElement will include the default xmlns where needed if it hasn't already been defined.

So the solution in your case is to declare the xmlns on the root element, either explicitly in the XML literal or by using the Imports declaration.