Re: Are web components *seriously* not namespaced?

On 5 February 2015 at 20:55, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Fri, Feb 6, 2015 at 12:48 AM, Glen <glen.84@gmail.com> wrote:
> > So in other words it *is* a case of "it's good enough". Web components
> are
> > quite possibly the future of the web, and yet we're implementing them to
> be
> > "good enough" in "90%" of use cases?
> >
> > jQuery is JavaScript which means that it's different for various reasons:
> >
> > 1. It's less important to keep the names short.
> > 2. It's possible to rename a plug-in if there is a conflict (e.g. @
> >
> http://stackoverflow.com/questions/11898992/conflict-between-two-jquery-plugins-with-same-function-name
> )
> > 3. It's a library, not something built into the browser, which means
> that if
> > jQuery decides to add some form of namespacing, it doesn't require a
> major
> > specification and implementation by 5+ major browsers, etc.
>
> Web Components are also JS.  Any renaming you do in JS, you can do
> just as easily in HTML.
>
> >> Complicating things further simply isn't all that necessary.
> > Complicating it for the developer, or the implementers? I can't speak for
> > the latter, but for developers, this would be an *optional* feature. If
> you
> > don't have conflicts you don't *have* to alter an element's NS prefix,
> but
> > specifying the prefix in your HTML would provide rich IDE functionality,
> so
> > I don't see why anyone would *not* want to do this.
>
> Again, namespaces are nothing more than an indirection mechanism for
> prefixes, so you can write a long and more-likely-unique prefix as a
> shorter prefix that you know is unique for your page.  No
> functionality is enabled by namespaces that can't be done without them
> just as easily but with a little more verbosity.
>
> >> It's something that can be added organically as necessary.
> > Anne has already made a point about this, but also consider the fact that
> > without real namespacing, we're forced to name based on *potential*
> > conflicts. For example, in the ms- case, ms- may either already exist, or
> > *potentially* exist and be useful, so I name my element mks- instead.
> > Therefore I'm not able to give something the name that I want it to have,
> > for fear of future conflicts.
>
> Anne pointed out that XML Namespaces screwed this up, not that it's
> not easy to get right.
>
> You don't need to fear future conflicts.  Googling for a name is often
> sufficient.  You can change later if there is a conflict.
>
> > Even just being able to optionally shorten a custom element's NS prefix
> can
> > be useful. For example, if a vendor uses <excalibur-grid>, we can just
> > change that to <x-grid> and things will be easier to type, cleaner, etc.
> >
> > Regarding XML, I never even mentioned XML in my initial post, so I'm not
> > sure what all the fuss is about. This can be implemented in a way that
> > supports both HTML *and* XHTML/XML, yet doesn't look at all like XML
> > namespacing. The only important part is the use of URIs, I can see no
> better
> > way of providing both a unique namespace, as well as an endpoint for
> > gathering human- & machine-readable data about a set of custom elements.
> Is
> > there something inherently wrong with this? Or is this just about people
> > being too lazy to type a closing tag, because that can remain optional.
>
> Most people who mention namespaces on the web are referring to XML
> Namespaces, so I assumed you were as well.  Your suggestion is shaped
> exactly like XML Namespaces, with the use of urls as namespace, etc.
>
> >> They [XML namespaces] have a number of terrible affordances
> > +
> >> Most of them don't commit the same mistakes that XML namespaces did
> > Such as?
>
> A few are:
>
> * URLs are not a good fit for namespaces. Humans make a number of
> assumptions about how urls can be changed (capitalization, trailing /,
> http vs https, www or not, etc) which are often true for real urls due
> to nice server software, but are not true for urls, which are opaque
> strings.
> * There's no consistency in the URL structure used: some namespaces
> end in a word, some in a slash, some in a hash, etc.
> * You can't actually fetch namespace urls.  Again, they're opaque
> strings, not urls, so there's no guarantee or expectation that there's
> anything useful on the other side, or that what is on the other side
> is parseable in any way.  As a given XML namespace becomes more
> popular, fetching the namespace url constitutes a DDOS attack; the
> W3C, for example, has to employ sophisticated caching to prevent
> namespace url requests from taking down their website.
> * URLs contain a bunch of extra typing baggage that don't serve to
> uniquify anything, just make it longer to type.  The "http://" prefix,
> for example, is identical for all namespaces (and if it's not, it's
> one more hurdle for authors to run into).  Using a string with a
> higher information content is better for authors.
> * Domain names don't mean much. For example, Dublin Core's namespace
> starts with "http://purl.org/", which is effectively meaningless.
>

Note: For those that dont know, "purl" means "permanent URL".  During the
early days of the the semantic web link rot [1] started to develop as
people would create a system, then leave and it was no longer available.
For vocabs such as dublin core it was deemed important that the URL could
be stable and permanent in line with "COOL URIs dont change" [2].  Lately
work has been done on w3id.org as a community maintained resource to do the
same.

[1] http://en.wikipedia.org/wiki/Link_rot
[2] http://www.w3.org/TR/cooluris/
[3] https://w3id.org/

* 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!)
> * The ability to redefine namespaces at various points in the tree
> make generic processing far more complicated than it should be, as
> <foo:bar> can refer to two completely different elements in different
> parts of the tree.
> * The ns prefix is actually significant - you can't just refer to an
> element by its expanded name, you *must* stuff the namespace into a
> prefix and use it.  Again, hard for generic processing.  It's
> impossible to just move an element from one part of the tree to
> another, because its prefix may have been redefined to mean something
> else, and you can't just expand away the prefix to make it
> unambiguous; instead, you have to maintain logic to check the prefixes
> in use on the element (and all of its descendants) in effect in the
> new location, and if there are any conflicts, rename the conflicting
> ones on the element (and its descendants) to new unique prefixes and
> associate those prefixes with the namespaces in question.
>
> 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.
>
> ~TJ
>
>