Opening Old Wounds

August 8, 2001

Leigh Dodds

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>

The familyName and firstName elements do not have an explicit namespace; but they are, nonetheless, on some interpretations, associated with the namespace 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 serious misuse.

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 elementFormDefault attribute, Michael Brennan among them.

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 The More Things Change Agile XML Composition Apple Watch Life After Ajax?

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.

To do this one needs to be able to trace the process from requirements through to formal specification. But, as the namespace debate again highlights, there are institutional impediments to tracking the process completely; in this case, the privacy policy of some W3C Working Groups. As for policies concerning public disclosure of Working Group activities, one might reasonably wonder whether publication of additional design notes supporting finished specifications would be a useful addition.

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?