[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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 [expletive deleted], but maybe it [expletive deleted] less than the status quo (and in any case [expletive deleted] 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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|