Yossi Dahan commented here on being surprised by the implications of the elementFormDefault option in XSD schemas, and particularly in relation to BizTalk.

I don't find the behavior surprising myself anymore, as I already was familiar with the implications of elementFormDefault. In reality, this is something that I don't particularly like about XSD, as I find that leaving it to "unqualified" can lead, as Yossi found out, to some weird looking schemas (at least for me). Mind you, regardless of this option, qualified-ness of an element can also be enabled/disabled for each element individually.

There are, however, 2 things that make this option more obscure than it should be:

1. The default value defined in XSD for elementFormDefault is "unqualified".
2. When you install BizTalk, now Visual Studio will have 2 different templates for XSD schemas. The original one in Visual Studio has elementFormDefault="qualified", while the one installed by BizTalk doesn't specify elementFormDefault (thus leaving it in the default value of "unqualified"). Which one you get depends on the context in which you use the Add New Item menu in VS.

In general, I recommend always watching out for this issue and always explicitly setting elementFormDefault to the appropriate value. In my mind, that appropriate value should always be "qualified" for new schemas .

Also, just for the sake of completeness, it is worth saying that, under the XSD specification, all root elements defined in a schema are always qualified (i.e. should be associated to the XML targetNamespace of the schema). The elementFormDefault only controls whether child elements are qualified or unqualified. This is why the elementFormDefault option doesn't really "drop namespaces" from the XML document instances; it merely restricts it to the root elements.

XSD, BIzTalk