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: <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..
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..
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.?
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
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?