Yossi Dahan [BizTalk]

Google
 

Thursday, August 23, 2007

elementFormDefault in schemas

This is one of those things that, when finally spotted, leave you wondering how on earth you could have not notice them before. in fact -I'm not quite sure I do fully understand this even now, so I'll be very interested in hearing other people's thoughts on this.

I'm working on the integration with a 3rd party web service and they send us their specification. Their request schema looks something like:


First thing I did was to add this schema to a BizTalk project and generate an Xml instance, which looked like:


This buffeled me for a while as, unlike what I've expected (and if I'm not mistaken), requestField1 and requestField2 do not "belong" to the "3rdPartyNamespace" namespace, but rather to an empty namespace.

I was expecting the Xml to look like -


But, as is apparent from the screen shot, VS was not happy (nor was the XmlValidatingReader class when I checked)

In order to make that last Xml valid I had to modify the schema and set the elementFormDefault attribute of the schema to qualified.

Having read a little bit about the elementFormDefault I now officailly decalre that "I don't like it!" - mostly because it can effectively be used to "drop" namespaces from schemas (created or imported) and by doing this mis-represent how the xmls should looked like.
Note: I guess this statement deserves a blog post by it's own, but I'm not going to go there (at least not now), I'm just interested in getting the schemas in my project correct, which would definitely, at this point, involve making sure they are all, always, qualified (and I believe they are, as I usually make the point of setting it explicitly, luckily).

I'm not quite sure why this is the default behaviour if this attribute is not specified, but that’s a question for the W3C, what is even more interesting is that BizTalk introduced a new behaviour here to Visual Studio, which only further confused me -

If you add a new item to a BizTalk project by right clicking on it in the solution explorer and selecting "Add New Item" - the schema generated for you will not include the elementFormDefault attribute and so it will effectively be unqualified; if you do the same on a c# project or simply ask Visual Studio to create a new xsd file (outside the context of a BizTalk project, using the File menu) the schema generated will include the elementFormDefault="qualified" attribute.

Another bit that confused me is that I thought that by adding the "xmlns" and "targetNamaspace" attributes at the root of the schema I effectively tell the schema all child elements should belong to the same namespace, but this is not the case, of course, the way to look at this, I guess, is that a schema is, of course, an xml document, so these attributes simply refer to the namespace of child elements of the schema, which in my case is irrelevant as they are all prefixed by "xs:"
I don't know how the 3rd party guys created their schema, but it looks like they've missed the same point as I did and hopefully, assuming I'm right, they will consider changing it to be qualified; in the meantime - I though it is worth sharing this point.

Labels: ,

0 Comments:

Post a Comment

<< Home