Re: Are web components *seriously* not namespaced?

Austin,

Second on the problem with namespaces and Sparql. I spend a significant
amount of code in my sem apps getting the application to manage these,
rather than the querant. It's also at least one reason why I think that
many ontologists tend to go to a single namespace, even where there are
usually fairly strong type correlations and inheritance that can be
signaled in Sparql. Manage those namespaces and prefix as type signifier
usually becomes much more useful.

> We're dealing with Web Scale here. "Works for 90% of us" isn't good
enough.

Yup. This is my problem with HTML5 in general - while there are some
benefits to creating "simplified" HTML (the biggest being partial
rendering, which XML is still struggling with via the streaming APIs) the
most highly touted benefit - the Aunt Gladys dictum (HTML should be
simplest enough that your Aunt Gladys should be able to write it)  - has
always seemed specious to me. HTML5 is the only programming language I'm
aware of that doesn't specifically require syntactical integrity. Not
surprising, that tends to add considerably to both the browser's overhead
and the likelihood of misrendering. I think this is even more true for web
apps.



Kurt Cagle
Principle Evangelist, Semantic Technologies
Avalon Consulting, LLC
kurt.cagle@gmail.com, personal
caglek@avalonconsult.com, business
443-837-8725



On Fri, Feb 6, 2015 at 2:30 PM, Austin William Wright <aaa@bzfx.net> wrote:

>
>
> 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.
>