[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

unobtrusive namespaces and imaginary namespaces

• From: Liam Quin <liam@w3.org>
• To: XML Developers List <xml-dev@lists.xml.org>
• Date: Wed, 9 Sep 2009 21:19:44 -0400

At the Balisage markup conference in Monrteal last month
I presented  proposal relating to namespaces in XML,
http://www.w3.org/2009/Talks/08-quin-balisage-namespaces/
(I have annotated the slides a little)

1 Introduction
==============

The main purposes are
(1) to come up with a mechanism that "makes legitimate" the
    HTML 5 namespace behaviour, in which (for example) an
    svg element in the midde of an HTML document introduces
    a new default namespace, without any explicit signal in the
    document;

(2) to allow "namespace mashups" in which anyone can define their own
    mixture of namespaces - e.g. docbook and xforms -- and yet still
    have the "unobtrusive" lack of explicit signals in the
    document;

(3) to support XML validation of documents using unobtrusive
    namespaces;

(4) to introduce a mechanism for distributed extensibility, e.g. so
    a Web browser could in the future introduce other namespaces
    or so that people could make their own mashups reasnably easily

(5) to reduce the pain of the namespace syntax for everyone.

Some design goals from the original namespaces spec are not
addressed except to note that I do not propose getting rid of
the current mechanism -- you'd be able to intermix them, in fact.

* identifying an authority for a metadata vocabulary (RDF)
  not addressed; use the existing mechanism.

* copy and paste names from one document to another, and have
  the same names now be in the namespace of the new document:
  addressed

* copy and paste names from one document to another, and have
  the same names stillbe in the namespace of the original document:
  not addressed; use the existing mechanism.


2. Unobtrusive Namespaces
=========================

The proposal is to make a new attribute; since only the W3C XML Core
Working Group can allocate names starting with "xml" I'll use nsd
for my attribute name for now.

The attribute points to a "namespace definition".

What's that?, you ask!  I'm glad you asked.

A namespace definition might look like this -- I don't actually
care about the syntax except that you must not need to understand
the existing namespace syntax to use it, so, no colons!

<nsd>
    <ns name="students" uri="http://www.example.org/students">
        <element name="svg" ns="svg" />
    </ns>
    <ns name="svg" uri="http://www.w3.org/2000/svg" />
</nsd>

A document could use this nsd file like this:
    <first-years nsd="students.nsd">

Within this document, an element <svg>....</svg> would be
placed in the svg namespace:

    <first-years nsd="students.nsd">
      <campus-map>
        <svg> some drawing here </svg>
      </campus-map>
    </first-years>

is now the same as

    <first-years xmlns="http://www.example.org/students">
      <campus-map>
        <svg xmlns="http://www.w3.org/2000/svg"> some drawing here </svg>
      </campus-map>
    </first-years>

or,

    <std:first-years xmlns:std="http://www.example.org/students">
      <std:campus-map>
        <svg:svg xmlns:svg="http://www.w3.org/2000/svg">
          some drawing here
        </svg:svg>
      </std:campus-map>
    </std:first-years>

With this mechanism, I no longer need the syntax in the document,
and yet software that needs to tie special behaviour to the
namespace behaviour can still do so.

The nsd attribute can appear on any element, of course.

An nsd file can include another one.  Here is a more
complex example:

<nsd>
  <ns name="students" uri="http://www.example.or/students">
    <!--* include SVG diagrams *-->
    <element name="svg" ns="svg" />

    <!--* a "tutor" attribute on any element in the
        * students namespace is actually in the staff
        * namespaces; you could do the same for xlink
        * attributes for example, or xsi:type.
        *-->
    <attribute name="tutor" ns="staff" />

    <!--* the hobbies element can contain HTML markup: *-->
    <element name="hobbies">
      <element name="*" ns="html" />
    </element>
  </ns>
  <ns name="html" uri="http://www.w3.org/1999/xhtml" />
  <ns name="svg" uri="http://www.w3.org/2000/svg" />
  <ns name="staff" include="staff.nsd" />
</nsd>

This is the example I used at Balisage (I've added the
comments).

Note that, in the event of conflict, two namespaces
having the same element, you either have to use the nd file to
disambiguate, or you have to use the existing namespace syntax.

ISO DSRL might give a way to rename elements, and if that was
supported by Web browsers and XML processors, if would be
another approach.

3. Imaginary Namespaces.
========================

We could write (fairly easily) an nsd file for HTML5.

An HTML 5 Web browser *already behaves as if it used exactly
such an nsd file*

So let's pretend it does.  What if the HTML5 spec said that
there was a default nsd file, and a Web browser had to behave
as if it used that file?

Of course, it would be even nicer if you could supply your own
nsd file to override the default, but it's more than I think is
needed right now.

Liam

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

• Follow-Ups:
  • Re: unobtrusive namespaces and imaginary namespaces
    • From: rjelliffe@allette.com.au