XIN: XML implicit namespace definitions

[Liam Quin <liam@w3.org>]

I've been thinking for a while about this proposal.

There are a couple of probably show-stopping problems with it,
but bear with me, if you will.

Consider for a moment an XHTML document that uses SVG, MathML and
XForms.  And for SVg we need XLink too.

  <xhtml
    xmlns="http://www.w3.org/1999/xhtml";
    xmlns:svg="http://www.w3.org/2000/svg";
    xmlns:m="http://www.w3.org/1998/Math/MathML";
    xmlns:xlink="http://www.w3.org/1999/xlink";
    xmlns:xforms="http://www.w3.org/2002/xforms";>

That's a lot to remember, so people use copy and paste, and
before long you get other namespace declarations in there too.

In practice, though, almost all elements here are going to be
unambiguous if you take their ancestors into account, and
attributes too.

Imagine having an XML vocabulary (or some other mechanism)
that says, in this context, the following elements are in
the following namespace, and in this other context, the following
elements and attributes are in this other namespace, and so on.

Let's call it "myxhtml.xin", (for XML implicit namespaces).

A xin file, in this imaginary world, contains a list of these
implicit namespace bindings, and can also refer to other xin
files by URI.  A xin processor could cache these files, of course,
and could ship with a pre-generated cache of some well-known
xin files.

So I can say, <xhtml xin="myxhtml.xin"> and move the above
declarations to that file on my server.  Or I could say,
<xhtml xin="http://www.example.org/xin/xhtml+mathml+svg+xforms.xin";> 
(we could actually use w3.org of course), and if that was a well-known
URI, or if the format of the URI was well-known, the xin processor
wouldn't need to look at it (the xin processor would probably be
updated more often than the xin file).

One can imagine a javaScript implementation fairly easily, for
Web clients, and it's easy to see how to process this in XSLT,
in Java, perl, C, etc.  for the Web, even server-side XSLT would
be cheap.

Now, here's the snag.

Sometimes, you do need to disambiguate.
The following file might be well-formed XML, but whether it is or not,
it is not namespace-well-formed, and the Web browsers I tried reject it:

  <try xin="try.xin">
    <svg:picture>pretty!</svg:picture>
  </try>

A workaround here is to use a different character:

  <try xin="try.xin">
    <svg.picture>pretty!</svg.picture>
  </try>

I don't like that very much but it would work.

It's also possible a XIN file could point to other resources,
such as various sorts of schema for various purposes, XSLT or
XQuery fragments for making RDF (RDFa/GRDDL) and so forth.

The main benefits you get are
(1) your XML documents are simpler and smaller
(2) it's easier to remember the xin file than a mass of URIs
(3) you dereference xin files and cache them -- they are not names --
    so whether there is a trailing slash or not, whether there's a #
    at the end, whether characters are escaped or not, makes no
    difference, an architectural improvement.

The main downside is that it sucks, but maybe it sucks less than
the status quo (and in any case sucking isn't always bad...)

A secondary downside is that when you rely on something not
ubiquitous, you risk losing some interoperability.

My question is, is anyone interested and does it sound useful?
Does anyone want to help me experiment with implementations?

It's not inconceivable to me that such a thing could get into a
future version of XHTML, and/or get fairly widespread support,
if it was useful.

Liam

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