Opening Old Wounds
August 8, 2001
This week's XML-Deviant explores a namespace debate that has resurfaced on XML-DEV and wonders whether a few rays of sunshine could dry up this and other debates once and for all.
A Debate Resurfaces
In a recent XML Deviant article, "Schema Scuffles and Namespace Pains", Edd Dumbill summarized a debate on XML-DEV concerning the use of unqualified child elements within explicit namespace associated parents. For example,
<foo:person xmlns:foo="http://best.practice.com"> <familyName> KAWAGUCHI </familyName> <lastName> Kohsuke </lastName> </foo:person>
firstName elements do not have an explicit
namespace; but they are, nonetheless, on some interpretations, associated with the
of their parent element. On some interpretations is the key issue here. Some
developers see this interpretation as perfectly acceptable, while most see it as a
W3C XML Schemas allows this practice through the elementFormDefault attribute, which specifies whether the target namespace is associated with locally declared elements in a schema. The default value is "unqualified", that is, elements will not have a namespace.
The debate was sparked again following the publication of Simon St. Laurent's SAX Filters for Namespace Processing. These filters allow an explicit association of unprefixed child elements (e.g. familyName above) with a parent element's namespace. Some concern was voiced over the prospect of the side-effects of their unguarded use. But careful application of the filter could benefit those preferring to use explicit namespace associations.
Some XML-DEV members laid the blame for this kind of namespace usage at the feet of the W3C XML Schema specification. David Cleary vehemently denied that this was the case.
XML Schema has not introduced unqualified child elements. Also, it was not in XML Schema's charter to only support a subset of XML. Unless there were technical reasons something couldn't be done and there was a plausible explanation for it, it had to be supported. Whether it is good or bad practice, something I'm not arguing, is irrelevant. People were free to do it before Schema and people are still free to do it after Schema.
One aim, in Cleary's view, of the W3C XML Schema specification was to model all well-formed XML documents. Since using unqualified child elements is legal, XML Schemas has done its job successfully, regardless of whether the practice is well or ill-advised.
Stepping back for a moment, it's good to note that there were few explanations for why someone might produce documents in this way. Ronald Bourret explored object serialization, which had been suggested as a use case, but failed to come up with a reason why explicit namespaces couldn't be used. Sean McGrath added a further twist by observing that you don't need namespaces to do this anyway if one relies solely on the hierarchical document context. However there are some fairly obvious problems that caused by unqualified elements as Tim Bray commented.
Many took issue with the chosen default for the
Michael Brennan among
Perhaps the fact that the "elementFormDefault" attribute on the schema element defaults to "unqualified" if not explicitly specified contributes to this. I think one would reasonably expect the defaults to point users toward best practices, not bad practices.
Francis Norton called the default choice "cavalier" in light of the absence of any clear justification.
I accept the points about unqualified local elements not redefining namespaces or XML. But I am still baffled and, to be honest, a bit upset by the cavalier way that the spec sets a default of "unqualified" and endorses what so many of us regard as worst practice, without giving a strong justification or rationale. Is there a strong J. or R.? If not, why did those who opposed in the WG give way? If there is, why not tell us about it?
The Deviant probed this aspect of the debate in order to discover why the present
default value for
elementFormDefault was chosen. Understanding the
underlying decision might shed some light on the issue. It would certainly help the
developer community assess the decision and its implications. And yet the answer to this
question is accessible only to W3C members. If you're lucky enough to be one, then read
on here. If not then you're left with only two life-lines: Ask the Audience or, if
you're really lucky, Phone A Friend.
Best Practices Once More
Also in XML-Deviant
This debate raises the best practice issue once more. A contentious feature in the XML Schema specification has been highlighted. Unfortunately, because, as Tim Bray put it, "the sucker's been finalized and blessed and shipped", there's little prospect of seeing it altered. We're then left with best practice as a guide.
The real goal for the development community is to explore the output of the W3C, particularly its recommendations, and see how well they perform within different processing contexts. Few contentious features of any specification are clearly good or bad; they're usually somewhere in between. Judgments on best practices must be qualified by their applicability to particular environments. Hands-on experience is obviously a critical factor, but this must be supplemented by an understanding of the origins of particular features, why they have been provided, and for what purpose.
After all, if the W3C is supposed to be the research lab of the internet, why can't we inspect the research notes as well as the completed deliverables?