Well, not in this case anyway…
It’s become axiomatic in some circles — especially in WS-* land, as well as in many other uses of XML — that the preferred (or only) means of offering extensibility is through URI-based namespaces, along with a flag to tell consumers when an extension needs to be understood (a.k.a. mustUnderstand).
The reasoning is that extensibility should be as easy as possible. By leveraging one registry — DNS — you can use URIs to allow anyone to create your own uniquely identified vocabulary, without any overhead of co-ordination.
This is often contrasted (and deemed superior) to the approach of the IETF, which uses IANA to manage many a namespace, requiring prospective registrants to jump through a variety of hoops to get in.
For those unaware, I am one who preaches to anyone willing to listen, or not listen for that matter, that without XML Namespaces, extensibility is a pipe dream. As such, why am I now suggesting this is no longer the case?
I’m not… You’ll need to read Mark Nottingham’s above linked post and follow-up comments from other members of the community, which includes my own, to understand what I mean. But just to be sure that I don’t send a confusing, contradictory message to those who choose not to follow the above link, I still believe XML Namespaces to be at the fundamental core of XML-based application extensibility. Of course, from an application perspective, whether the term used is namespace, or classpath, or whatever else, the need to differentiate the signature of any given class, or associated method/function is obvious. But when you get past the application stack, things change.
As such, I agree COMPLETELY with what Mark has to say. Read on to find out just what that is…