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:
- The default value defined in XSD for elementFormDefault is “unqualified”.
-
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.
