RE: [xml-dev] XIN: XML implicit namespace definitions

["Michael Kay" <mike@saxonica.com>]

I proposed something very similar in the context of XPath: the notion that a
namespace could be defined as a union of other namespaces. So you could have
a namespace bound to prefix rss that is the union of the rss0 and rss1
namespaces, so that path expressions using this prefix will match either.
Equally a function namespace could in effect be bound to a path containing
multiple function libraries, and you would search all those libraries for
the right function to call.

This would actually remove one of the reasons why it's currently a really
bad idea to change namespaces between versions of a spec.

Michael Kay
 
> -----Original Message-----
> From: Liam Quin [mailto:liam@w3.org] 
> Sent: 24 March 2009 16:09
> To: xml-dev
> Subject: [xml-dev] XIN: XML implicit namespace definitions
> 
> 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/
> 
> ______________________________________________________________
> _________
> 
> 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@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org List archive: 
> http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>