Re: Are web components *seriously* not namespaced?

On Thu, Feb 5, 2015 at 12:55 PM, Tab Atkins Jr. <jackalmage@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.