Re: Are web components *seriously* not namespaced?

Tab,

I spend the vast majority of my time anymore in RDF-land, where namespaces
actually make sense (I'm not going to argue on the XML use of namespaces -
they are, agreed, ugly and complex). I know that when I've been at Balisage
or any of the W3 confabs, the issue of namespaces ex-XML has been hotly
debated, and many, many potential solutions proposed. Regardless, I do
think that there is a very real need for namespaces in the general sense,
if only as a way of being able to assert conceptual domain scope and to
avoid collisions (<div> is the prototypical example here).

Now, I'd like to see clark notation more heavily used, both on the XML and
HTML side - <{http://www.w3.org/2001/XMLSchema#}string> is ugly but
unambiguous. CURIE notation works so long as you assume that context
changes within a scoped entry, and that a curied name, whether <ms:foo> or
<ms-foo> must always be closed - ie,

<div>This is a <ms:glossary><term>glossary term</term></ms:glossary></div>

would change internal scope, such as on <term>, to the innermost declared
ancestor (ms:glossary). This is actually very consistent behavior for web
content in particular, and one area I think XML got wrong.

Re: formation of IRIs - I normally declare namespaces for RDF using non URL
notation such as "urn:uuid:12334592125" or something similar, avoiding
http: protocols, precisely for the confusion from neophytes working with
namespaces.  Java classes use similar namespace notation:
"com.oracle.java.Foo" in establishing namespacing into their framework. The
problem that I see with the 90% argument is that everyone's remaining 10%
is different, and those are the cases where namespacing - as a context
establishing mechanism becomes useful.

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



On Thu, Feb 5, 2015 at 11:55 AM, 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.
> * 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
>
>