slanted W3C logo
Cover page images (keys)

Unobtrusive Namespaces

Simplifying and Enabling

Liam Quin

Images from www.fromoldbooks.org used by permission. Photographs by Liam Quin.

The Perceived Problems

Some people dislike namespace syntax

HTML 5 draft violates layering

Can't define namespace mashups/mixins

Constraints on solutions

Must not require understanding of current syntax in most cases

(i.e. don't improve something by making it harder)

Must not require central registration: must be distributed

Must not break existing XML documents

Must work in today's typewr Web browsers and XML applications

(note, Web browsers require namespace-wellformedness, and ignore DTDs)

Who are we helping?

People authoring documents by hand (including XHTML5)

(often not very sophisticated in nuances of the specs)

People extending vocabularies, e.g. making mashups like XHTML+MathML+GeoML+SVG

(remove the need to remember who defines what in a mashup)

Other technologies

Henry Thompson's Default Prefix Declaration

(does not work in existing Web browsers)

Pragmatic Namespaces from Micah Dubinko, hardwires a list of prefixes, and uses dots for namespaces, e.g. <ch.ac.cern.html>

explicit coupling of namespace and element removes ambiguity, sometimes good, sometimes bad; the use of the dot breaks existing content

James Clark has blogged about namespaces too.

Unobtrusive namespaces

Proposal: Unobtrusive Namespaces

Remove the need for prefixes in almost all documents;

Allow the use of prefixes where it makes sense (e.g. RDF) or where disambiguation is needed;

Namespace Definition File assocates elements and namespace URIs, and can include other NDFs

Proposal: Invisible Namespaces

Any XML application (including Web browsers) is allowed to have a default Namespace Definition File;

The file does not have to exist or be read (hence imaginary) as long as the application behaves as if it eisted.

Users can augment the default with an NDF of their own, but this cannot redefine elements in the default NDF

hence, Web browsers can do incremental rendering before fetching any user-supplied NDF

Benefits of Proposal

Can work in existing Web browsers

XSLT and XQuery can be used to supply explicit xmlns declarations

Removes the need for people to understand namespaces until they are ready

With (almost) everything in the default namespace, there's much less syntax

Supports mashups, you can say, my namespace is SVG + MathML + GeoML or whatever

Allows same treatment for HTML 5 and for XML/XHTML

Drawbacks of Proposal

Namespace declarations separated from documents (NDFs ameliorate this a little)

Still need full xmlns:foo="bar" sometimes, e.g. for conflicts or for XLink

No way to declare a default prefix, since Web browsers enforce NS-wellformeness; could use dot or underscore instead

A JavaScript implementation is possible for the Web, but changing the DOM can break other scripts

Conclusions

Maybe a mixed proposal has the most possibilities.

Should we have a workshop to try to decide whether to think about maybe possibly doing something?

Or should we just choose one and see what happens?

Questions?

liam@w3.org, Liam R. E .Quin