(unknown charset) Unobtrusive Namespaces, Imaginary Nmespaces

I wrote up what I hope to be a clearer account of the proposal
that I'd presented in August at Balisage, and that I'd sent to
the HyperText Coordination Gorup.

It's a starting point for saying, hey, we publish XML, as
long as we don't hurt it too much, we can change it ;-)

The idea is define the HTML 5 behaviour with respect to namespaces
in such a way that XML systems could be [changed to be]
compatible, by defining an external file that a Web browser
wouldn't need to load, but an XML processor would, in order
to define how some elements (e.g. "svg") change the default
namespace.

Coincidentally, it turns out that this mechanism offers
some benefits with respect to "distributed extensibility" and
also means that in most cases people don't need to use
prefixes and messy syntax when using XML namespaces.

Writeup online at
http://www.barefootliam.org/xml/20091111-unobtrusive-namespaces

Text version follows...

Please cc me in any email replies.

[[
Unobtrusive Namespaces

The HTML 5 draft has the idea that, in HTML, certain elements can
automatically introduce a new default namespace.  Currently these
elments are html, svg and math, although it's easy to imagine others
being added in the future.

This idea is not currently compatible with the way namespaces work. in
XML, you have to do one of two things to introduce a new namespace;
either:

1. Use an xmlns pseudo-attribute on the element you want to
   introduce the new namespace, or,
2. Use a DTD to supply such an attribute, by giving it a default (or
   fixed) value.

Now, HTML 5 gets rid of the idea of a DTD: there's no DOCTYPE
declaration, for example, with SYSTEM and/or PUBLIC identifiers. And
there's no sign that the browser vendors are willing to revisit that
decision.  So that leaves us with an explicit xmlns pseudo-attribute,
and that also doesn't sit well with the HTML 5 people.

Jumping up and down and yelling at HTML 5 people to use more syntax so
that HTML 5 looks more like XML isn't working. But wait, can we change
XML in some way so that we have a way to describe this default
namespace behaviour? Let's say it's OK to do this in XML, and find a
way to make it OK, and then it won't bea problem, right?

Well, namespace declarations are not the only issue, it turns out, but
bear with me for a moment, let's see how far we get with Unobtrusive
Namespaces, and then we'll take it even further and make Imaginary
Namespaces, which address this need of HTML 5.

The idea of Unobtrusive Namepsaces, then, is to take away as much of
the syntax as possible—ideally, all of the syntax—from the document,
much as Unobtrusive Javascript did. Let's imagine that an XML processor
(I'll come back to HTML browsers in a moment) understands an attribute
nsd="svg", and that the meaning of this attribute is that a particular
namespace definition is to be used. That namespace definition is a URI
(a relative URI here), with the understanding that the well-known URI
for the HTML namespace definition is built in to the Web browser and
need never be loaded. But what does it do?

A namespace definition can do any of:

1. give a list of elements, and associate namespace URIs with them

2. define an element/attribute pair, to put the named attribute into
   a different namespace (this is to work round what I see as a
   deficiency of XLink, as used e.g. in SVG)

3. refer to another namespace definition

This combination of features lets you make namespace mashups; it also
is enough that we can define the HTML 5 behaviour. Even better, you can
define your own extensions, use them with no explicit namespace prefix,
and, if they later become part of HTML, your documents will continue to
work unchanged! How cool is that?

Of course, a Web browser doesn't want to fetch an extra file. This is
where the concept of Imaginary Namespaces comes in.  With Imaginary
Namepsaces, we write into a spec such as HTML 5 the namespace
definition file that an implementation must use, or must behave as if
it uses. But the user agent doesn't actually need to load the file.
After all, the whole idea was to change XML rather than asking HTML to
change.

So, I'm proposing the following:

1. A default namespace definition file for HTML 5 to be mentioned in
   the HTML 5 specification.

2. Web browsers continue to behave in the same way as now.

3. For added brownie points, Web browsers would fetch namespace
   definition files if they are mentioned (and are not in the browser's
   cache, of course). However, such files would only ever augment the
   standard definition, so that the browser could render the document
   up to the first unknown attribute or element without waiting for the
   namespace definition file to load.

4. XML processors could load the namespace definition files, or, one
   could use XSLT (or XQuery) to read the namespace definition file and
   produce XSLT that, when ran, would add the correct namespace nodes
   to a document. In this way, one could validate the document and
   process it with existing XML tools.

5. Existing namespace syntax is in no way affected by this proposal.
   Existing XML documents would continue to work exactly as now.

6. Ideally, Web browsers should also understand XML namespace syntax
   in documents, for people using e.g. mathml or SVG editors, or
   trying to serve XHTML as text/html for compatibility (= broken
   software workaround) reasons. But my proposal isn't about existing
   namespace syntax, it's about Unobtrusive (and Imaginary) namespaces.

7. If a namespace definition file actually listed all the names in a
   given namespace, you could use it to validate your use of a namespace
   in some way. That's not a deliberate goal of this proposal, but it's
   a way that some people have said they'd like to use it, as a sort of
   very light-weight schema language.

Finally, what should a namespace definition file actually look like?
Here is one proposal; I'm open to other syntax, as long as people
working with namespace definitions do not need to understand
traditional XML namespace syntax! It's this requirement, for
example, which seems to rule out the related ISO DSRL draft.

<nsd>
  <html>
    <uri>http://www.w3.org/1999/xhtml</uri>
    <svg>
      <uri>http://www.w3.org/2000/svg</uri>
      <attribute>
	<name>href</name>
	<uri>http://www.w3.org/1999/xlink</uri>
      </attribute>
    </svg>
  </html>
</nsd>

I'm not committed to this syntax; I've tried to make it simple,
reasonably redundant so that you can get good error messages, and only
just powerful enough to do what's needed. The syntax I proposed at
Balisage in Montreal was slightly more complex; you can see it linked
to one of the slides I used (that presentation was aimed at suggesting
to an XML audience that we could improve namespaces by making them
useful and practical, but it was not written for Web developers, who
don't need to be persuaded that there are problems with namespaces
today, and perhaps do need to be persuaded that it's worth having
consistent rules between HTML and XML).

So that's it. It won't affect JavaScript APIs, it won't give Web
browsers ways to understand unknown markup if they don't have any
underlying code, but it does give a way to identify extension points in
a way that lets them become part of the standard in the future, and,
for authors, it reduces the cost of using namespaces.

]]

Liam

-- 
Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/ * http://www.fromoldbooks.org/

Received on Thursday, 12 November 2009 03:13:11 UTC