Liam,

I like THAT proposal a great deal. It would solve a lot of problems,
especially with generated content (XQuery in particular can be a real bear
for namespaces, especially when you need to use higher order functions
(calls and the like) in order to performs certain somewhat stickier
generation problems.

It also may be the best solution for the HTML crowd. If you could do
something like:

<LINK rel="namespaces" type="text/xmlns" ref="mynamespaces.xml">

then you can get handle multiple "default" namespaces without needing to
insert nasty looking (to the HTML crowd) prefix disambiguators for most
cases. For those cases where you do have prefix collisions, then the source
namespace document could include those prefixes to disambiguate on a needed
basis.

Moreover, it seems like a good solution to the issue of implicit default
namespaces - mathml, svg, etc. The W3C establishes a default namespace list,
probably based upon the WICD list, for HTML 5 document conformance. There
are reserved and implicit:

<LINK rel="namespaces" type="text/xmlns" ref="
http://www.w3.org/xmlns/default.xml">

would not need to be explicitly stated. You COULD override them explicitly
at some point with a namespaces document that includes something in an added
namespaces document -

<namespaces>
    <namespace uri="http://www.mysvgextender.com/svg/xmlns" prefix="svg"
mode="override"/>
</namespaces>

or could specify that the namespaces in the given space also augment the
existing namespaces for disambiguation purposes:

<namespaces>
    <namespace uri="http://www.mysvgextender.com/svg/xmlns" prefix="svg"
mode="extends"/>
</namespaces>

Hmmm ... trying to see a downside here and having a hard time finding a good
use case where it wouldn't work ...

Kurt Cagle
Managing Editor
http://xmlToday.org


On Thu, Aug 6, 2009 at 10:17 AM, Liam Quin <liam@w...> wrote:

> On Wed, Aug 05, 2009 at 08:46:18AM +0100, Dave Pawson wrote:
> > On 08/05/2009 07:29 AM, Liam Quin wrote:
> [...]
>
> > >Some differences --
> > >* I want people to be able to write a "namespace definition"
> > >   that would let them combine namespaces...
> > >
> > >* I don't think it's a good idea to hard-wire any namespaces,
> > >   but I'm OK with an application-specific default namespace
> > >   definition file that can be overridden by an author.
> >
> >
> > Are you going to expand on these two please Liam?
>
> Sorry for being gnomic and rushed in my note...
>
> > Define combine?
> > Hard wire as in 'define the ns association in the instance'?
> >   How else might it be done? In the schema?
> > Do you mean 'author' or XML application?
>
> I proposed here (and in somewhat modified form for Balisage next week)
> the idea of a miniature schema, a namespace definition file, that
> (1) identifies elements that introduce a new default namespace, and
> (2) can refer to other namespace definition files.
>
> I would use a single attribute to refer to a namespace definition file
> on my top-level element in my instance, or at any other subtree.
>
> "I" here is document author, although an application (such as a
> Web browser) could have a default namespace dfeinition file.
>
> In this way, I can for example define XHTML such that a math element
> (say) automatically implies the MathML namespace, an svg element
> similarly; and I can handle the fact that hred in SVG is in the xlink
> namespace.
>
> But I can also make my own namespace, and arrange that elements
> within it are automatically assigned to other namespaces as
> needed, without extra markup in the document.  I suppose the
> modern way to describe this would be "unobtrusive namespaces" :-)
>
> So that's the sense in which I could combine namespaces.
>
> A disadvantage is that I did not have a good way for explicitly
> disambiguating by adding prefixes.
>
> Liam
>
> --
> Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
> http://www.holoweb.net/~liam/ <http://www.holoweb.net/%7Eliam/> *
> http://www.fromoldbooks.org/
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@l...
> subscribe: xml-dev-subscribe@l...
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>