elementFormDefault is an attribute of the xs:schema element.
It defaults to 'qualified'. That means nested local element definitions,
their names are in the target namespace. So, if you have
Examples:
<foo xmlns="myURI>">42
That is, you must explicitly go to the no-namespace syntax. It doesn't happen implicitly.
This trait is mixed into things that are affected by elementFormDefault.
Namely the local element declaration class.
,
<tns:foo><bar>42</bar></tns:foo>
In this case you really don't want to setup xmlns='myURI' because this happens:
,
<foo xmlns="myURI"><bar>42</bar></foo>
But if elementFormDefault='unqualified', the instance doc would be like:
Now a DFDL/Xpath expression to reach that 'bar' element looks like /tns:foo/tns:bar
Contrarywise, if elementFormDefault='unqualfied'...
...
}}}
Now a path to reach element bar would look like /tns:foo/bar.
See how 'bar' isn't preceded by the tns prefix. That's becasue the child elements are
all 'no namespace' elements.
This also affects what a result document is like from namespaces perspective.
Suppose the above 'bar' element is an xs:int. Then with elemenFormDefault='qualified', an
instance would look like:
elementFormDefault is an attribute of the xs:schema element. It defaults to 'qualified'. That means nested local element definitions, their names are in the target namespace. So, if you have
<foo xmlns="myURI>">42
That is, you must explicitly go to the no-namespace syntax. It doesn't happen implicitly. This trait is mixed into things that are affected by elementFormDefault. Namely the local element declaration class.
<tns:foo><bar>42</bar></tns:foo>
In this case you really don't want to setup xmlns='myURI' because this happens:
But if elementFormDefault='unqualified', the instance doc would be like:
<tns:foo><tns:bar>42</tns:bar></tns:foo>
or the possibly nicer (for a large result)
Now a DFDL/Xpath expression to reach that 'bar' element looks like /tns:foo/tns:bar Contrarywise, if elementFormDefault='unqualfied'...