On Thu, Feb 5, 2015 at 12:55 PM, Tab Atkins Jr. <jackalm...@gmail.com> wrote:
> > * Domain names don't mean much. For example, Dublin Core's namespace > starts with "http://purl.org/", which is effectively meaningless. > It means that the owner of purl.org decided to allocate the namespace, as opposed to someone else. So while it's not arbitrary, for our purposes it's entirely opaque. > * Similarly, path components often exist which are worthless and just > lengthen the namespace for no uniquifying gain, such as the SVG > namespace http://www.w3.org/2000/svg which contains /2000/ for some > historical reason (it was minted in 2000, and at the time the W3C put > the year in most urls for some reason). (Note the use of www in this > url, compared to no www in the DC namespace. Inconsistency!) > URIs are opaque, it's not really worth it to argue about how they're designed, because their design is meaningless to everyone except the authority that minted them. Every once in a while in the RDF/Semantic Web community, there's a complaint that <http://www.w3.org/1999/02/22-rdf-syntax-ns#> is too long to remember. Eventually the discussion realizes that it's a non issue because, again, URIs are opaque. If you have to look up a URI, <http://prefix.cc/xsd> (for example) works pretty well. If you type, auto-complete, copy/paste, or otherwise enter the wrong namespace, it'll be pretty clear right off the bat that your program isn't working. Even if that weren't the case, we have spell-checkers, why not namespace-checkers? (snip) > I'll stop there, though I could name a few more. All a namespace > needs is to be of reasonable length so that it's probably unique. > There are any number of non-insane ways to do that, but XML namespaces > chose many of the worst options possible. > I would call the namespace issue largely /resolved/ by XML. All of the features you named exist because it adds a definite feature; e.g. the ability to paste an SVG document directly into a document without having to copy-paste a bunch of headers (Turtle, SPARQL has this problem; nested namespaces are a definite *feature*!). XML namespaces are greatly preferable to the tag-soup problem we have with text/html and application/json, where there's *no* namespaces whatsoever, with *no* way to mix vocabularies, and *no* forward compatibility. Nothing against JSON; I maintain numerous utilities around JSON including JSON Schema, JSON Hyper-schema, JSON-LD, and more. JSON documents are great for what they do; XML (and other DOM serializations) documents are great for the different task that they do, and they do namespaces. If nothing else, we need to support namespaces because HTML isn't the only DOM-based hypertext technology out there. Limiting our sights to HTML would be unfortunate. I'm not even sure how namespaces are unsupported; namespaces exist in the DOM, even if they don't exist in the text/html syntax. It's not terribly hard to use: var svgns = 'http://www.w3.org/2000/svg'; // functionally same as xmlns=, @prefix, etc document.getElementsByTagNameNS(svgns, 'svg'); var e = document.createElementNS(svgns, 'rect'); ... this is not fundamentally different than all the DOM stuff we do for HTML. We're dealing with Web Scale here. "Works for 90% of us" isn't good enough. Austin Wright.