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.