W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: Are web components *seriously* not namespaced?

From: Kurt Cagle <kurt.cagle@gmail.com>
Date: Fri, 6 Feb 2015 12:11:44 -0800
Message-ID: <CALm0LSHyi3BGsXYfJE-7hjjFjf6LTc5rQ5m5yrtwMqi4c4hJGQ@mail.gmail.com>
To: Dimitri Glazkov <dglazkov@google.com>
Cc: Arthur Barstow <art.barstow@gmail.com>, Glen <glen.84@gmail.com>, public-webapps <public-webapps@w3.org>
I'm inclined to agree with Glen here on a couple of points.

1) The exact form of the namespacing mechanism isn't so important as the
fact that there is a mechanism in place. While not everyone will use
namespaces (and to be honest that should be seen as a requirement, that any
namespace proposal should account for that 90% case that Tab laid out
earlier where namespaces are an encumbrance) I think that the sooner such a
namespacing mechanism be put into place, the sooner that it can be adopted
by the 10% who do in fact have significant need for namespaces (semantic
web being the biggest use case I can think of at the top of my head).

2) I tend to distrust public registries - they add a layer of complexity
and often are underutilized when finally implemented. I'm more inclined to
see something like a namespace bundle or package that can be written in
JSON in some kind of standardized format. Node's *npm* might be a good
model there. This creates a set of bound key prefixes for a given site that
can in turn be associated with corresponding "namespaced globals" and
extended HTML elements. I'd have to think about this a bit, but I could see
this both as a way to allow for large organizations to manage its widget
usage within web apps.

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

On Fri, Feb 6, 2015 at 9:01 AM, Dimitri Glazkov <dglazkov@google.com> wrote:

> On Fri, Feb 6, 2015 at 4:05 AM, Arthur Barstow <art.barstow@gmail.com>
> wrote:
>> Dimitri - if someone wants to provide input (f.ex. requirements ) for
>> this API, should they add them to the above bug (or do you recommend else)?
> Yep. That's a good place.
> :DG<
Received on Friday, 6 February 2015 20:12:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:43 UTC