elementFormDefault
elementFormDefault is like a good character actor – you tend to overlook it until something isn’t quite right.
I Married Joan
Technically, Gilligan’s Island would be the same with someone other than Jim Backus playing Thurston Howell III just like that show about pompous Star Fleet officers is technically the same even when key crew are replaced by Po, Tinky-Winky, La-La and Dipsy. But it wouldn’t be quite right. The interpretation would be off.
The story is similar for elementFormDefault. People smarter than I know the full ramifications of “qualified” and “unqualified”. They also know the definition of the term: elementFormDefault specifies whether locally declared elements are namespace qualified, and can likely explain it so I and a group of 4 year olds could understand. For me, the definition is simple: when elementFormDefault is "unqualified", things aren't quite right with XML files output by BizTalk Server. Technically correct, but not quite right.
For example, given a flat file containing error messages with a header/body/trailer structure like so:
Los Angeles Facility
ERROR102|0|High|I can’t escape from new york|1981-05-31T13:20:00.000-05:00
ERROR16502|2|Low|The Love Boat hit an iceberg|1978-05-31T13:20:00.000-05:00
8675309
Create header and trailer schemas, then create a body schema that picked up the repeating error elements: ID, status, priority, description, dateTime. The first few lines of the body schema look like this:
<?xml version="1.0" encoding="utf-16"?>
<xs:schema xmlns:b="https://schemas.microsoft.com/BizTalk/2003" xmlns="https://Sample.Error" elementFormDefault="unqualified" targetNamespace="https://Sample.Error" xmlns:xs="https://www.w3.org/2001/XMLSchema">
Notice that elementFormDefault is “unqualified”. This is the default value. So what happens when I throw this schema into the Flat File Disassembler component and run it from the command line? Let’s find out:
set TOOLSDIR="C:\Program Files\Microsoft BizTalk Server 2006\SDK\Utilities\PipelineTools"
%TOOLSDIR%\FFDasm sample.txt -bs Error.xsd -hs Header.xsd -ts Trailer.xsd
Through the magic of the internet, two output files are produced (you did remember to set the Error node’s maxOccurs attribute to 1 right?). The files are easy to spot – they’re the ones with GUIDs. Opening one reveals:
<Error xmlns="https://Sample.Error">
<Error xmlns="" >
<ID>16502</ID>
<Type>2</Type>
<Priority>Low</Priority>
<Description>The Love Boat hit an iceberg</Description>
<ErrorDateTime>1978-05-31T13:20:00.000-05:00</ErrorDateTime>
</Error>
</Error>
Notice the empty namespace declaration xmlns=””. For more complex schemas, the “extraneous” xmlns tags are more noticable. Probably not what you want but technically correct – yet something isn’t quite right. Now change elementFormDefault to “qualified”, run the flat file disassembler command-line tool again and bask in the difference:
<Error xmlns="https://Sample.Error">
<Error>
<ID>16502</ID>
<Type>2</Type>
<Priority>Low</Priority>
<Description>The Love Boat hit an iceberg</Description>
<ErrorDateTime>1978-05-31T13:20:00.000-05:00</ErrorDateTime>
</Error>
</Error>
A parser would happily eat both versions but this later version is more pleasing. It seems more correct, just as it is correct that Lee Van Cleef was the banjo-playing deputy on the Andy Griffith Show.
The sample is attached as a zip.
Banjo-Playing Deputy?
So where does this leave us? How about a recommendation:
Always set elementFormDefault to “qualified”.
It won't hurt anything if you do, and your XML output will be more pleasing.
And if you are using the XML or Flat File disassembler component and have a body section that you want broken out, make sure the maxOccurs attribute of the root node for the body is set to 1. If you forget this and ask a newsgroup, you may look like a noob.