XML prefixes and the elementFormDefault property
In a previous entry I had written about business objects and how within WebSphere Process Server they are compartmentalized by something called a "namespace". It should also be known that these business objects are represented in the XML form throughout the server as well and adhere to the rules layed out by XML standards regarding XML schemas. It is for this reason that certain traces within the server, as well as the output of APIs such as the BOXMLSerializer will display your business object data in XML form.
A common issue that comes up with many WebSphere Process Server customers is when the outputted XML does not look quite right or is not what was being expected. In this entry, I would like to focus on the inclusion or exclusion of a namespace or namespace prefix for the elements of an XML structure and why what may look incorrect is in reality valid XML output or can be altered by toggling a property in your schema definition.
The most important thing to understand is that the parsers and APIs utilized in WebSphere Process Server have a lot of the behavior determined by how the schema (in other words, the .xsd file representing your business object definition) is set up.
For example, let's use a simple XML instance like this:
First, we can show what a namespace prefix is by stating that the above is identical to this XML:
The only difference here is that we have defined a prefix of "pre" that resolves to the namespace of "http://testNamespace" and prefixed the Parent element with it. This is useful especially when child element may need the namespace declared (we will touch on this shortly) and you don't want to have to add an xmlns declaration on each child element.
Now, while the above two XML instances are the same, they indicate different things dependent on how the actual XML schema that defines this structure is set up. Particularly, an XML schema has an optional attribute called elementFormDefault, which can have a value of "unqualified" or "qualified". If the attribute is not specified, the default is "unqualified". For the "unqualified" case, the above XML is stating that BOTH the Parent and Child elements are defined within the http://testNamespace namespace. This is because in the "unqualified" case, it is not needed to declare the namespace explicitly at every level, but instead child elements inherit the namespace of their parent element. This means that until you hit a child element defined in a different namespace than the parent, you won't be seeing any additional xmlns declarations or prefixes on the elements.
Conversely, if the schema has the elementFormDefault attribute set to "qualified", then the above examples indicate that Parent is defined in the http://testNamespace but that Child is defined in the null namespace. In order for the XML to match a schema where qualified is set and both Parent and Child are defined in the http://testNamespace the XML would have to look like:
which can also be expressed as below, not using prefixes:
<Child name="Matt" xmlns="http://testNamespace">
If you are interested, please see the XML Schema documentation.
This is a great place to see what the standards say and how to obtain the output you desire.