namespaced content has failed

Namespaced content on the Web has failed.

It's been tried by numerous groups, before microformats, and after. It's even been tried in the context of RSS and RDF, and in practice people write
scrapers that look for namespace prefixes as if they are part of the element name, or perform literal string matches on common namespace prefix uses (e.g. 1), not as mere shorthands for namespace URIs.

If you want to carry on a theoretical discussion of namespaces, please do so elsewhere, for in practice, discussing them is a waste of time, and
off-topic for microformats lists.

namespaced content is not well supported

Namespaces are actually *not* well supported in sufficient modern browsers, nor even sufficiently with enough W3C technologies or test suites as compared to (X)HTML + semantic-class-names + CSS.

articles documenting the failure of namespaced content

The mixed namespace approach has already been tried by *numerous* others since 1998 and has failed on the Web.

implementation experience lacks beneficial anecdotes

I had dinner with friends who write software. It seems to me that when people who have had to deal with Namespaces in XML can talk freely, they never have anecdotes about how Namespaces have helped them. Instead, they have negative comments. OTOH, devil's advocate scenarios where Namespaces could help come from people who don't have to deal with Namespaces as part of their work.

namespaces for content are a negative

namespaced content discourages interoperability of data

Namespaces encourage people to seclude themselves in their own namespace and invent their own schema rather than reusing existing elements in existing formats. This hurts interoperability because a dozen different namespaces can all have their own slightly different semantics for the same element. See BuildOrBuy for support for this argument, specifically

Use somebody elses rather than making aliases on purpose. It's one thing to make your own and then discover that there's something equivalent out there. It's quite another to willfully clutter the semantic web with aliases; the latter increases the burden on the community of consuming your data, so it's anti-social.

If you start thinking about the web in terms of OOP and polymorphism, namespaces break the polymorphic model that allows you handle widely varied data structures using the same methods.

example of fundamental software engineering error

Namespaces are an example of the Fundamental Software Engineering Error, which is that something too terrible to actually use can be fixed by adding a level of indirection. Sometimes that is true but software engineers try to do it even when it clearly is not.

bound prefixes are an anti-pattern

Copy-and-paste brittleness. Copy-and-paste of the source becomes very brittle when two separate parts of a document are needed to make sense of the content.

Hard for authors. Prefixes are notoriously hard for authors to understand.

More indirection adds difficulty Fundamentally, prefixes are an indirection model. Indirection models are very, very hard for people to understand.

Hard for implementors. Prefixes are notoriously hard for implementors to get right.

Hard for dynamic content situations. Prefixes in dynamically changing content are even worse because they require than an observing software agent not only track the value that they are concerned about, but also all possible ways for the value's prefixes to change meaning.

Basically, adding bound prefixes to any language or format design adds fragility, difficulty of use, difficulty of implementation, and in general must be avoided.

namespaces unnecessary in practice

In practical use cases for marking up visible data (and others), namespaces, bound prefixes etc. have never been necessary. E.g.[1]:

namespaces cause dogmatic noise

It appears the desire for abstract bound (or literal) prefix namespaces causes a small strongly outspoken minority, especially on email lists, to frequently post long messages in apparent attempted support for namespaces as a concept, technology, add-on, feature etc., without bases in real world use cases. They often state namespaces themselves as the real world use case, which is of course, tautological. For example, see archives of public-html on w3.org in 2009.

It's not clear what about namespaces incites this primarily religious/dogmatic/tautological behavior among some individuals, but the behavior itself is quite unproductive (noise in community communications channels), and thus undesirable and explicitly discouraged.

non-namespaced techniques have been succeeding

On the other hand, XHTML + semantic-class-names (aka POSH) has seen widespread adoption among the web authoring/design/IA/publishing community. Microformats is leveraging the approach that is both working better and frankly dominating in practice on the Web.

more

Well, what about hAtom?

It doesn't use namespaces because "entry-" just part of the name, rather than a prefix that is associated with a URL.

In this case the prefix "entry-" means nothing more than "entry-". Each of those three specific terms is so specific to the problem domain that we invented names specifically for them. For example, "entry-title" isn't any old title, it's specifically the Atom concept of a title.

Each of those three terms is defined on its own, fully spelled out with the "entry-" part of their name, in the hAtom spec.

You can't pair "entry-" with some arbitrary other word (even existing microformats property name) and have it work or even mean anything. Thus "entry-" is not a stand-alone prefix, and has no defined meaning or function on its own, contrary to anything even resembling a namespace.

I think it's a problem for collaboration where the subcommunities interact at the W3C if one subcommunity wants things and another bears the cost.

There a previous example in the form of inflicting permanent complexity (i.e. cost) onto an adjacent subcommunity: Namespaces in XML wasn't something that the SGML documentation community (turned into XML community) needed. Instead, Namespace in XML were a requirement posed by the Semantic Web community's RDF/XML. This requirement permanently complicated the processing model for the SGML community turned into XML community: http://www.flightlab.com/~joe/sgml/sanity.txt

I think URIs (directly or through indirection) are more clumsy as identifiers than short names. Since RDF vocabularies use URIs as identifiers, I find creating more microformats (even if they need more one-off speccing) a more appealing way forward from the language usage point of view than importing RDF vocabularies in a generically mappable way. (I can't see how generic mapping can be had without using URIs as identifiers.)

...

I think indirection via prefixes is bad, because experience with Namespaces in XML shows that it confused people a lot. Both full URIs and short prefixed names where the fixed prefix doesn't expand into anything are better.

...

we should refuse a mechanism that can reasonably be expected to have a relatively high failure probability. As the toolchain becomes longer, the probability of failure increases, since it takes only one tool in the chain to fail for the whole chain to fail.