Amy actually touches on a critical question - is the difficulty in the
namespaces, the prefixes, the underlying conceptual mapping, or the tools
involved in accessing this content?

I'd contend that at least a part of the problem is in the tools - DOM tools
especially. Consider for instance such lovely examples as
getElementsByTagNameNS(name,namespace). Given that most client-side web
developers now work with libraries designed for ease of use rather than
strict formalism, it's perhaps not surprising that this particular function
is seldom invoked ... if you're used to typing $("div"), it's perhaps
understandable that
$("input","http://www.w3.org/2002/xforms") might seem to beg the question
about utlility.

This actually points to what I see as a failure of leadership on the part of
the W3C. There was, for a time, a number of language developers who were so
frustrated with working with DOM implementations that they created their own
languages for working with XML in their respective linguistic idioms. E4X,
XJ, Duce, Linq and so on were all examples of this approach. The W3C could
have become involved in these efforts, perhaps created a simpler abstraction
language that more accurately echoes the dot convention used by nearly every
C-based language on the planet - an effort which would have in turn made it
easier for these other languages to create a true lingua franca for
imperative XML manipulation. It didn't. That failure meant that when AJAX
exploded on the scene in 2004/5, XML manipulation generally got left by the
wayside, even though there were some compelling technologies that could have
been contenders (E4X was a big one). Instead, the W3C got bogged down in
RDF/OWL, pretty much leaving XML to rot on the vine.

I'd also contend that while most of the people on this list are used to the
notion that a prefix is essentially just a temporary placeholder for a
namespace, for many people, especially those struggling with XML, a prefix
is perceptually carved in stone. The "xsl" namespace is for XSL, the "xs"
namespace is for XSD (or XSDi), the "atom" namespace is for atom, and these
namespaces are immutable. I suspect a part of this comes from the fact that
in most of the languages that most people are exposed to, the closest thing
to a namespace is a class, and class names in nearly all languages (except
XML) ARE immutable. The current system *is* more flexible (and I'm not
advocating a change at this late date) but I have long suspected that a
central problem with namespaces has been this very point.

There's one other problem with namespaces, which kickstarted this who
discussion in the first place. HTML doesn't have them. Most HTML generator
libraries do not use them, there are no NS: buttons on most web page editor
programs. If you're using an XML editor like Spy or Oxygen, namespaces
generally aren't a problem because people who work with those tools
generally *do* understand the concepts, but most pure HTML editors don't
have the same level of namespace autoselect, the ability to associate a
global namespace or the ability to render anything *but* HTML. Because of
this, most people don't even encounter namespaces even at a conceptual
level, and as a consequence, namespaces are essentially invisible to most
people, are hideously ugly and confusing to HTML devs because they don't
understand them, and of value only to that small segment of the population
that live, eat and breathe XML every day.

Houston, we have a problem.

Kurt Cagle
Managing Editor
http://xmlToday.org


On Thu, Jul 9, 2009 at 7:23 PM, Amelia A Lewis <amyzing@t...> wrote:

> On Thu, 9 Jul 2009 17:59:56 -0700, Jim Tivy wrote:
> > I would love to hear of some success or horror stories of
> multi-namespaces
> > in authoring content.  Anyone out there doing this in DITA, DocBook, open
> > office...
> >
> > What ever happened to the compound document?
>
> Web services are an obvious use case.  It's true that SOAP is
> execrable, but the 'simplest subset' continues to drive it: there's an
> "envelope" namespace, which indicates 'this is a message conforming to
> certain expectations' (that breaks down when you add in the headers and
> the ws-* interoperability mess; perhaps that's a namespaces
> counterexample?), and the content is in some other namespace.  That
> namespace defines its own rules.  You can't create a "carrier"
> namespace without the ability to say something about the content
> carried; HTML5 is a rather brilliant example of how limited such
> content would be if Powers That Be had to approve every message dialect.
>
> Several XML dialects are designed for inclusion in other dialects--SVG,
> MathML are obvious ones.  XPath is an interesting case: it's not an XML
> dialect, but does need to be able to navigate arbitrary dialects.
> Compare the rigidity and complexity of CSS selectors for a
> counterexample.  If XML namespaces weren't such a horrible muddle,
> there would probably be more such dialects (and less resistance from,
> for instance, HTML proponents, to adopting the technique).
>
> "Microformats" are an example where namespaces would be valuable, but
> since microformats are typically HTML-based, instead the designers are
> typically forced to contort a limited set of elements and attributes
> into unnatural shapes to carry the message.  Sure, you and I can agree
> that "<abbr class="key 42">moltuae</abbr> is an encoding for the
> meaning of life, the universe, and everything, but it's ... somewhat
> non-obvious, shall we say.  Providing a means of extensibility would
> enable, in HTML 5, microformats (which are probably not intended for
> display in the browser, but which are nonetheless valuable to their
> intended users).
>
> On a side note ... someone, I think it was Jim Tivy, suggested in an
> earlier message that attributes ought to be in the default namespace.
> I would suggest that that's not a good idea.  If you think of
> attributes as having a "namespace" scoped by their containing element,
> things are a lot more clear.
>
> The "no-namespace" or "global" namespace (xmlns="") is where elements
> live if they're not assigned to a namespace.  It should be obvious that
> if you have multiple dialects from different authorities competing for
> names in that namespace, you're going to lose, probably quickly.  The
> same is not true of attributes; attributes in "no namespace" are scoped
> by their parent element--a single authority.
>
> <p class="important">Blah</p> current state, html as default namespace
> <html:p class="important>Blah</p> current state, xmlns:html=html
> namespace
> <html:p html:class="important">Blah</p> proposed change.  take
> attributes out of their parent's namespace and into the default
> namespace, and *every* *attribute* of every element in a non-default
> namespace now has to be prefixed, even though it's governed by the same
> authority that defined the default namespace.
>
> The scoping of attributes to their container elements is often
> confusing to people new to XML, but it is, in my opinion, the right
> decision (given the verbosity that would otherwise be introduced).
>
> As they stand, namespaces in XML are awkward and clumsy (needlessly so,
> as others have already pointed out, using for example the Java package
> style technique for establishing a namespace authority, which is fully
> as general as the URIs-that-aren't-really-URIs defined by the
> namespaces spec), but not broken ... until you encounter prefixes in
> content, at which point ... it's broken.  Is it broken because of
> namespaces, or because of namespace prefixes in content?  Well, given
> the choice of (uselessly verbose and special-character-studded) URIs as
> the namespace identifier, it's hard to demand that they be replicated;
> lots of folks are willing to complain about the replication of the
> prefix "aliases" anyway.  Clark notation, after all, would solve the
> problem ... but hasn't been widely adopted, and I think for exactly
> that reason.
>
> Amy!
> --
> Amelia A. Lewis                    amyzing {at} talsever.com
> "How does one hate a country, or love one? ... What is love of one's
> country; is it hate of one's uncountry? Then it's not a good thing. Is
> it simply self-love? That's a good thing, but one mustn't make a virtue
> of it, or a profession."
>                -- Therem Harth rem ir Estraven
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@l...
> subscribe: xml-dev-subscribe@l...
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>