I predict that sometime around 2025, we will end up redefining namespaces
because the number of jQuery-like components have ballooned into the
millions, the web has descended once again into a sea of interoperability,
and registries will, once again, have proven to be a bottleneck, as they
have EVERY SINGLE TIME they have been implemented.

Of course, they won't be called namespaces, and they'll probably use a dash
instead of a colon , and they definitely won't be XML based because
everyone knows that XML is EVIL ... (sigh) !

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

On Wed, Feb 4, 2015 at 2:58 PM, Tab Atkins Jr. <jackalm...@gmail.com> wrote:

> On Thu, Feb 5, 2015 at 8:31 AM, Glen <glen...@gmail.com> wrote:
> > I know I'm rather late to the party, but I've been doing a lot of reading
> > lately about web components and related technologies, and the one thing
> that
> > confounds me is the fact that web components appear not to have any
> "real"
> > namespacing.
> Prefix-based informal namespacing appears to be more than sufficient
> for 90%+ of use-cases.  It works fine, for example, for the huge
> collection of jQuery widgets/extensions.  Complicating things further
> simply isn't all that necessary.
> We do plan to help solve it at some point, as Dimitri says, as there
> are some cases where real namespacing is useful.  In particular, if
> you have a name that you can assume is globally unique with high
> confidence, you can actually share custom elements across documents.
> Within a single page, however, prefix-based informal namespaces are
> nearly always sufficient.
> XML Namespaces are a pox on the platform, however, and they'll
> definitely not get reproduced in custom elements.  They have a number
> of terrible affordances.
> ~TJ

Reply via email to