- From: (unknown charset) Liam Quin <liam@w3.org>
- Date: Wed, 11 Nov 2009 22:13:10 -0500
- To: (unknown charset) HTML WG <public-html@w3.org>
I wrote up what I hope to be a clearer account of the proposal that I'd presented in August at Balisage, and that I'd sent to the HyperText Coordination Gorup. It's a starting point for saying, hey, we publish XML, as long as we don't hurt it too much, we can change it ;-) The idea is define the HTML 5 behaviour with respect to namespaces in such a way that XML systems could be [changed to be] compatible, by defining an external file that a Web browser wouldn't need to load, but an XML processor would, in order to define how some elements (e.g. "svg") change the default namespace. Coincidentally, it turns out that this mechanism offers some benefits with respect to "distributed extensibility" and also means that in most cases people don't need to use prefixes and messy syntax when using XML namespaces. Writeup online at http://www.barefootliam.org/xml/20091111-unobtrusive-namespaces Text version follows... Please cc me in any email replies. [[ Unobtrusive Namespaces The HTML 5 draft has the idea that, in HTML, certain elements can automatically introduce a new default namespace. Currently these elments are html, svg and math, although it's easy to imagine others being added in the future. This idea is not currently compatible with the way namespaces work. in XML, you have to do one of two things to introduce a new namespace; either: 1. Use an xmlns pseudo-attribute on the element you want to introduce the new namespace, or, 2. Use a DTD to supply such an attribute, by giving it a default (or fixed) value. Now, HTML 5 gets rid of the idea of a DTD: there's no DOCTYPE declaration, for example, with SYSTEM and/or PUBLIC identifiers. And there's no sign that the browser vendors are willing to revisit that decision. So that leaves us with an explicit xmlns pseudo-attribute, and that also doesn't sit well with the HTML 5 people. Jumping up and down and yelling at HTML 5 people to use more syntax so that HTML 5 looks more like XML isn't working. But wait, can we change XML in some way so that we have a way to describe this default namespace behaviour? Let's say it's OK to do this in XML, and find a way to make it OK, and then it won't bea problem, right? Well, namespace declarations are not the only issue, it turns out, but bear with me for a moment, let's see how far we get with Unobtrusive Namespaces, and then we'll take it even further and make Imaginary Namespaces, which address this need of HTML 5. The idea of Unobtrusive Namepsaces, then, is to take away as much of the syntax as possibleâideally, all of the syntaxâfrom the document, much as Unobtrusive Javascript did. Let's imagine that an XML processor (I'll come back to HTML browsers in a moment) understands an attribute nsd="svg", and that the meaning of this attribute is that a particular namespace definition is to be used. That namespace definition is a URI (a relative URI here), with the understanding that the well-known URI for the HTML namespace definition is built in to the Web browser and need never be loaded. But what does it do? A namespace definition can do any of: 1. give a list of elements, and associate namespace URIs with them 2. define an element/attribute pair, to put the named attribute into a different namespace (this is to work round what I see as a deficiency of XLink, as used e.g. in SVG) 3. refer to another namespace definition This combination of features lets you make namespace mashups; it also is enough that we can define the HTML 5 behaviour. Even better, you can define your own extensions, use them with no explicit namespace prefix, and, if they later become part of HTML, your documents will continue to work unchanged! How cool is that? Of course, a Web browser doesn't want to fetch an extra file. This is where the concept of Imaginary Namespaces comes in. With Imaginary Namepsaces, we write into a spec such as HTML 5 the namespace definition file that an implementation must use, or must behave as if it uses. But the user agent doesn't actually need to load the file. After all, the whole idea was to change XML rather than asking HTML to change. So, I'm proposing the following: 1. A default namespace definition file for HTML 5 to be mentioned in the HTML 5 specification. 2. Web browsers continue to behave in the same way as now. 3. For added brownie points, Web browsers would fetch namespace definition files if they are mentioned (and are not in the browser's cache, of course). However, such files would only ever augment the standard definition, so that the browser could render the document up to the first unknown attribute or element without waiting for the namespace definition file to load. 4. XML processors could load the namespace definition files, or, one could use XSLT (or XQuery) to read the namespace definition file and produce XSLT that, when ran, would add the correct namespace nodes to a document. In this way, one could validate the document and process it with existing XML tools. 5. Existing namespace syntax is in no way affected by this proposal. Existing XML documents would continue to work exactly as now. 6. Ideally, Web browsers should also understand XML namespace syntax in documents, for people using e.g. mathml or SVG editors, or trying to serve XHTML as text/html for compatibility (= broken software workaround) reasons. But my proposal isn't about existing namespace syntax, it's about Unobtrusive (and Imaginary) namespaces. 7. If a namespace definition file actually listed all the names in a given namespace, you could use it to validate your use of a namespace in some way. That's not a deliberate goal of this proposal, but it's a way that some people have said they'd like to use it, as a sort of very light-weight schema language. Finally, what should a namespace definition file actually look like? Here is one proposal; I'm open to other syntax, as long as people working with namespace definitions do not need to understand traditional XML namespace syntax! It's this requirement, for example, which seems to rule out the related ISO DSRL draft. <nsd> <html> <uri>http://www.w3.org/1999/xhtml</uri> <svg> <uri>http://www.w3.org/2000/svg</uri> <attribute> <name>href</name> <uri>http://www.w3.org/1999/xlink</uri> </attribute> </svg> </html> </nsd> I'm not committed to this syntax; I've tried to make it simple, reasonably redundant so that you can get good error messages, and only just powerful enough to do what's needed. The syntax I proposed at Balisage in Montreal was slightly more complex; you can see it linked to one of the slides I used (that presentation was aimed at suggesting to an XML audience that we could improve namespaces by making them useful and practical, but it was not written for Web developers, who don't need to be persuaded that there are problems with namespaces today, and perhaps do need to be persuaded that it's worth having consistent rules between HTML and XML). So that's it. It won't affect JavaScript APIs, it won't give Web browsers ways to understand unknown markup if they don't have any underlying code, but it does give a way to identify extension points in a way that lets them become part of the standard in the future, and, for authors, it reduces the cost of using namespaces. ]] Liam -- Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/ http://www.holoweb.net/~liam/ * http://www.fromoldbooks.org/
Received on Thursday, 12 November 2009 03:13:11 UTC