- From: Dan Connolly <connolly@w3.org>
- Date: Mon, 23 Apr 2007 15:52:20 -0500
- To: Murray Maloney <murray@muzmo.com>
- Cc: public-html@w3.org
On Thu, 2007-04-19 at 10:06 -0400, Murray Maloney wrote: > Are you suggesting that these problems are too great a barrier? > I am willing to accept that answer, I am just looking for someone > to back you up. > > Dan, is David correct on this? Do namespaces make HTML too difficult > to work with? Or is it all in how you look at it? Help me out here. A long time ago I argued that XHTML should have 3 namespaces, and that consumers should be prepared to deal with any of them. Back then, perhaps tools like SAX/Dom/XPath could have evolved to support it. They didn't, for whatever reason. By now, the cost of dealing with more than one XHTML namespace is nearly off the charts. Heck, dealing with *one* XHTML namespace is more than some people are interested in. > At 06:22 PM 4/17/2007 -0700, L. David Baron wrote: > >On Tuesday 2007-04-17 20:57 -0400, Murray Maloney wrote: > > > Seems to me that a namespace declaration on the root element would do the > > > trick. > > > That would be in keeping with Web Architecture and available tools. > > > Why not a namespace? > > > >To quote from something I wrote last year [6] about importing > >vocabularies into new namespaces (whether to use one technology > >within another or import elements from a previous version into a new > >version): > > > >This creates problems for both authors and implementors when multiple > >namespaces import the same vocabulary: > > > >1. When authors or implementors building on W3C technologies want to > > search for, select, or match a certain type of element, having that > > same element appear in multiple namespaces makes the necessary code > > more complicated. ... -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Received on Monday, 23 April 2007 20:52:40 UTC