Re: Are web components *seriously* not namespaced?

2015-09-21 Thread Henri Manson
I created a prototype of this idea on github:
https://github.com/hfmanson/webcomponentsjs/blob/xml-namespace/README.md by
forking the original webcomponents.js project.
It contains a working example of this concept. Below the content of the
README.md file:

This fork of webcomponents.js enhances Document.registerElement so that the
options argument can contain a 'namespace' property which contains an XHTML
namespaceURI e.g. http://mansoft.nl/big-blue-button so you can put a custom
element in another namespace than http://www.w3.org/1999/xhtml, which is
the default when no namespace is specified. The custom element registry is
now a 2 dimensional lookup table. First the namespaceURI is looked up and
then the localname of the custom Element. An example usage can be found at
https://github.com/hfmanson/webcomponentsjs/blob/xml-namespace/xmltests/brb-test-polyfill-ce.xhtml
Here two custom elements are defined with the same name 'bigbutton'
(without dashes) but with different namespaces "
http://mansoft.nl/big-red-button"; and "http://mansoft.nl/big-blue-button";.
When webcomponents.js is build you can test this file on a browser not
natively implementing Document.registerElement e.g. Firefox An important
change is to no longer use the HTML-specific onclick functions etc. but the
generic DOM AddEventListener pattern. The registration of the components
using the extra 'namespace' property is done in
https://github.com/hfmanson/webcomponentsjs/blob/xml-namespace/xmltests/bbb-component.js
and
https://github.com/hfmanson/webcomponentsjs/blob/xml-namespace/xmltests/brb-component.js
The example component 'Big Red Button' is based on a webcomponent sample
from Robin Berjon's presentation 'Distributed Extensibility: Finally Done
Right?' on XML Prague 2014.

When this will be implemented in the official Custom Element specification
it will be possible to polyfill XHTML with for example XForms by
implementing each XForm component using custom components. Or MathML.

I'll be happy to hear your comments and suggestions.


Re: Are web components *seriously* not namespaced?

2015-04-09 Thread Elliott Sprehn
On Thu, Apr 9, 2015 at 9:04 AM, Rahly  wrote:

>
>
> On Thu, Feb 5, 2015 at 4:12 PM, Kurt Cagle  wrote:
>
>>
>> ...
>>
>
> As a component designer, I'd like the ability to develop with a single
>  instead of .
>
>
>
You don't really need something quite this long, a 2-3 character prefix is
probably more than enough for most projects and libraries. You might use
 if you're making reusable components, or a two letter code for
your project if you're not, like "cal-" for calendar application widgets.

Since you must have a dash in the name anyway this isn't much overhead
either.

- E


Re: Are web components *seriously* not namespaced?

2015-04-09 Thread Dimitri Glazkov
On Thu, Apr 9, 2015 at 9:04 AM, Rahly  wrote:

>
>
> On Thu, Feb 5, 2015 at 4:12 PM, Kurt Cagle  wrote:
>
>> 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 ( is the prototypical example here).
>>
>>
> Although they are ugly, they did do one thing correct, and that was to
> place the burden of namespace resolution and use on the final document
> creator.  I think that namespace/prefix should be defined by the web page
> designer and not the component library designer. This allows end users of
> the component the ability to resolve the conflicts, instead of filing a bug
> report and a component designer has to fix all namespace resolutions.
>
> As a component designer, I'd like the ability to develop with a single
>  instead of .
>

This is a problem I would like solve as well.


>
> I definitely prefer the prefix solution as it "looks" cleaner in the end
> product.  document.registerElement should warn/error if the end product tag
> is already in use, that's for sure.
>

It already does:
http://w3c.github.io/webcomponents/spec/custom/#dfn-definition-construction-algorithm

:DG<


Re: Are web components *seriously* not namespaced?

2015-04-09 Thread Rahly
On Thu, Feb 5, 2015 at 4:12 PM, Kurt Cagle  wrote:

> 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 ( is the prototypical example here).
>
>
Although they are ugly, they did do one thing correct, and that was to
place the burden of namespace resolution and use on the final document
creator.  I think that namespace/prefix should be defined by the web page
designer and not the component library designer. This allows end users of
the component the ability to resolve the conflicts, instead of filing a bug
report and a component designer has to fix all namespace resolutions.

As a component designer, I'd like the ability to develop with a single
 instead of .

I definitely prefer the prefix solution as it "looks" cleaner in the end
product.  document.registerElement should warn/error if the end product tag
is already in use, that's for sure.


Re: Are web components *seriously* not namespaced?

2015-02-07 Thread Melvin Carvalho
On 5 February 2015 at 20:55, Tab Atkins Jr.  wrote:

> On Fri, Feb 6, 2015 at 12:48 AM, Glen  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 , we can just
> > change that to  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 

Re: Are web components *seriously* not namespaced?

2015-02-06 Thread Kurt Cagle
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.ca...@gmail.com, personal
cag...@avalonconsult.com, business
443-837-8725



On Fri, Feb 6, 2015 at 2:30 PM, Austin William Wright  wrote:

>
>
> On Thu, Feb 5, 2015 at 12:55 PM, Tab Atkins Jr. 
> 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  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,  (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.
>


Re: Are web components *seriously* not namespaced?

2015-02-06 Thread Austin William Wright
On Thu, Feb 5, 2015 at 12:55 PM, Tab Atkins Jr. 
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  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,  (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.


Re: Are web components *seriously* not namespaced?

2015-02-06 Thread Kurt Cagle
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.ca...@gmail.com, personal
cag...@avalonconsult.com, business
443-837-8725



On Fri, Feb 6, 2015 at 9:01 AM, Dimitri Glazkov  wrote:

>
> On Fri, Feb 6, 2015 at 4:05 AM, Arthur Barstow 
> 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<
>


Re: Are web components *seriously* not namespaced?

2015-02-06 Thread Dimitri Glazkov
On Fri, Feb 6, 2015 at 4:05 AM, Arthur Barstow 
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<


Re: Are web components *seriously* not namespaced?

2015-02-06 Thread Arthur Barstow

On 2/4/15 4:41 PM, Dimitri Glazkov wrote
The proposed solution is using registries: 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24578

Thanks Dimitri.

Glen - FYI, I added a link to the thread you started to the above bug 
(and embellished the bug's title a bit to reflect this thread).



The registry API hasn't been spec'd yet.


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)?


-ArtB




Re: Are web components *seriously* not namespaced?

2015-02-06 Thread Glen
Web Components are also JS.  Any renaming you do in JS, you can do 
just as easily in HTML.

+
No functionality is enabled by namespaces that can't be done without 
them just as easily but with a little more verbosity.
So I can import a custom element and rename it even after it has been 
registered?


Also, how do I get information about a custom element in my IDE of choice?

You don't need to fear future conflicts. Googling for a name is often 
sufficient.  You can change later if there is a conflict.
Seriously? And then I break all the code of users who depend on my 
element? So they rename it to the new name, and for them it conflicts 
with yet another element?


Most people who mention namespaces on the web are referring to XML 
Namespaces, so I assumed you were as well.
The only thing that was similar was the use of a URL, and I made it 
clear that this was just an example.


Regarding the use of URLs:

- You can just as easily misspell (or screw up a copy/paste) if you were 
using a URN or arbitrary string. Since the NS wouldn't match the one 
defined with the element, the element would fail to "run".


- "You can't actually fetch namespace urls" -- It would be made clear 
that the URLs should return certain metadata, if they don't then it's 
just a poorly maintained element.


- "URLs contain a bunch of extra typing baggage" -- Who types 
namespaces? Copy/paste.


- "Domain names don't mean much" -- that's why you can open the URL in a 
browser and find information about the element(s).


- "The ability to redefine namespaces at various points in the tree make 
generic processing far more complicated than it should be" -- This is an 
implementation detail that I cannot comment on, but it may be sufficient 
to just support declarations in the . I just thought that this 
would be useful in cases where you have less control of certain areas 
within your page (AJAX-loaded content, etc.).


- "The ns prefix is actually significant ..." -- Same as above.

All a namespace needs is to be of reasonable length so that it's 
probably unique
I agree, but "reasonable length" will be too long in the case of HTML 
elements. Go to "http://customelements.io"; and search for "x-". For 
example, "x-gif" has no identity. We can Google x-gif and get 5 x-gif 
elements, so now I have to search through my code to find the 
definition, and hope that there are comments etc. pointing to more 
information about the element.



There are any number of non-insane ways to do that ...

Good. So:

1. Are you thinking of using something like a URN? If so, will there be 
an endpoint that allows you to register your element and provide 
metadata that IDEs can query? It's a single point of failure, but it's 
better than nothing at all. (I think that arbitrary strings would 
probably be a bad idea)


2. Can you, or anyone else, agree with me that namespaces should be 
implemented sooner rather than later? Has this already been put to a 
vote? If so, have any of the vendors changed their minds?


I really think that this is important.

G.

On 2015/02/05 21:55, Tab Atkins Jr. wrote:

On Fri, Feb 6, 2015 at 12:48 AM, Glen  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 na

Re: Are web components *seriously* not namespaced?

2015-02-05 Thread Kurt Cagle
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 ( 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  or
 must always be closed - ie,

This is a glossary term

would change internal scope, such as on , 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.ca...@gmail.com, personal
cag...@avalonconsult.com, business
443-837-8725



On Thu, Feb 5, 2015 at 11:55 AM, Tab Atkins Jr. 
wrote:

> On Fri, Feb 6, 2015 at 12:48 AM, Glen  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 , we can just
> > change that to  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 

Re: Are web components *seriously* not namespaced?

2015-02-05 Thread Tab Atkins Jr.
On Fri, Feb 6, 2015 at 8:12 AM, Kurt Cagle  wrote:
> 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 ( is the prototypical example here).

Yes, as I've said, I don't disagree that we'll want a namespacing
mechanism at some point.  It's just not needed at the moment, and we
can safely introduce it in the future.

~TJ



Re: Are web components *seriously* not namespaced?

2015-02-05 Thread Tab Atkins Jr.
On Fri, Feb 6, 2015 at 12:48 AM, Glen  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 , we can just
> change that to  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 reas

Re: Are web components *seriously* not namespaced?

2015-02-05 Thread Glen
I like the look of a colon, however it would quite probably conflict 
with XML/XHTML so it's probably best to avoid it (although I am not an 
expert).


A hyphen or maybe even a tilde (~) would likely be the better option.

  

  

G.

On 2015/02/05 16:51, Melvin Carvalho wrote:



On 4 February 2015 at 22:31, Glen > 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.

Can someone explain why this is so, and what the justification is?
Or is it just a case of "it was too complicated, this is good enough"?

I see this has been brought up once before @
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0964.html,
but nothing changed.

It's not going to be long before  has been defined by
1,000,000 people (slight exaggeration), and you have no idea what
it is or where it came from without looking through
imports/scripts etc. Also you want to keep things short, so you
call your element  (you work for Monkey Solutions LLC),
but then someone else on the team is importing  from
Microsoft, and BAM!, you have another problem.

Why can't we do something like this?



var panel = document.registerElement("panel", {
namespace: "ms https://monkey-solutions.com/namespace";
});




var panel = document.registerElement("panel", {
namespace: "ms https://microsoft.com/namespace";
});






https://microsoft.com/namespace";
prefix="msft" />




You could also assign a prefix to all elements within a namespace
like this:

https://microsoft.com/namespace";
prefix="msft" />

You can override the prefix multiple times and the closest
 definition is used.

Please note that the above syntax is just an example of what could
be used.

Another BIG pro here is that IDEs can pull in information about
the elements by sending an HTTP request to the namespace URI so
that a tooltip could be displayed with an element description,
author, sample usage, etc.

I really do hope that it's not too late to make such a change.


+1 to everything

Could a colon perhaps be saved as a special character so in future you 
can have  and  and the user agent would be able 
to work out which code to use?



Regards,

Glen.






Re: Are web components *seriously* not namespaced?

2015-02-05 Thread Melvin Carvalho
On 4 February 2015 at 22:31, Glen  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.
>
> Can someone explain why this is so, and what the justification is? Or is
> it just a case of "it was too complicated, this is good enough"?
>
> I see this has been brought up once before @ http://lists.w3.org/Archives/
> Public/public-webapps/2013AprJun/0964.html, but nothing changed.
>
> It's not going to be long before  has been defined by 1,000,000
> people (slight exaggeration), and you have no idea what it is or where it
> came from without looking through imports/scripts etc. Also you want to
> keep things short, so you call your element  (you work for Monkey
> Solutions LLC), but then someone else on the team is importing 
> from Microsoft, and BAM!, you have another problem.
>
> Why can't we do something like this?
>
> 
> 
> var panel = document.registerElement("panel", {
> namespace: "ms https://monkey-solutions.com/namespace";
> });
> 
>
> 
> 
> var panel = document.registerElement("panel", {
> namespace: "ms https://microsoft.com/namespace";
> });
> 
>
> 
> 
>
> 
> https://microsoft.com/namespace";
> prefix="msft" />
>
> 
> 
>
> You could also assign a prefix to all elements within a namespace like
> this:
>
> https://microsoft.com/namespace";
> prefix="msft" />
>
> You can override the prefix multiple times and the closest 
> definition is used.
>
> Please note that the above syntax is just an example of what could be used.
>
> Another BIG pro here is that IDEs can pull in information about the
> elements by sending an HTTP request to the namespace URI so that a tooltip
> could be displayed with an element description, author, sample usage, etc.
>
> I really do hope that it's not too late to make such a change.
>

+1 to everything

Could a colon perhaps be saved as a special character so in future you can
have  and  and the user agent would be able to work
out which code to use?


>
> Regards,
>
> Glen.
>
>


Re: Are web components *seriously* not namespaced?

2015-02-05 Thread Glen
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.


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


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


Even just being able to optionally shorten a custom element's NS prefix 
can be useful. For example, if a vendor uses , we can 
just change that to  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.


> They [XML namespaces] have a number of terrible affordances
+
> Most of them don't commit the same mistakes that XML namespaces did
Such as?

G.

On 2015/02/05 00:58, Tab Atkins Jr. wrote:

On Thu, Feb 5, 2015 at 8:31 AM, Glen  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






Re: Are web components *seriously* not namespaced?

2015-02-05 Thread Tab Atkins Jr.
On Thu, Feb 5, 2015 at 3:57 PM, Benjamin Goering  wrote:
> Glad to see this. I was 'checking in' on the professional practicalities of
> custom elements earlier this week, and was pretty bummed when I couldn't use
> XHTML5 namespaces for my employer's organization.
>
> I build widgets all day. They run in inhospitable that websites I'm not in
> control of. They have so many globals I just can't even. I get planning,
> execution, and/or distribution friction when the standards prevent be from
> creating a truly universal web component that will work in all those
> environments.
>
> To Tab's point, I don't think that will prevent a 90%-sufficient solution,
> or one that is 99%-sufficient for some subset of the potential market.
> But I do agree with Kurt that eventually it seems like 'the right way'.
>
> It seems valuable today to at least standardize and have a spec for XHTML5
> Custom Elements (e.g. ). <1% of sites will actually use
> these in a way that fully validates against XHTML5. But at least web authors
> and developers will be using the web instead of Contrived JavaScript Embeds.
>
> With a vote of confidence (or better yet spec) on the consistency of XHTML5
> Custom Elements, I see no reason why I couldn't in the interim use this, and
> sleep at night knowing it will eventually be the way the web actually works:
>
> https://html.my-vendor.com/elements";>
> 
> 
>
> or
>
> https://html.my-vendor.com/elements";>
> 
> 
> 

Right now, those are invalid, and the document.register() call will
throw an error due to incorrect characters.

> One of the cool things about this is: Let's say in that last example I need
> to switch vendors or change where in the cloud my elements come from (e.g.
> QA, Staging, Production). All I need to change is the xmlns URL in that one
> attribute.

Namespaces do not enable this.  Switching the url of the script that
defines the elements does.  That can be done regardless of whether
namespaces are used or not, regardless of whether the elements have
the same name or different ones.

A namespace is literally nothing more than a convenience API over
prefix-based uniquified names, so you can define a long and
very-likely-unique prefix name without having to write it over and
over again.  It does not enable any new or unique programming models
or abilities.   and  are identical, except that it's
possible that "foo" is a label for a longer and more-likely-unique
prefix.

~TJ



Re: Are web components *seriously* not namespaced?

2015-02-05 Thread Tab Atkins Jr.
On Thu, Feb 5, 2015 at 7:44 PM, Anne van Kesteren  wrote:
> On Thu, Feb 5, 2015 at 2:15 AM, Tab Atkins Jr.  wrote:
>> Yes, real namespacing does eventually prove necessary as the
>> population grows.  That's fine.  It's something that can be added
>> organically as necessary; letting everything live in the null
>> namespace first doesn't harm future namespacing efforts.
>
> (It shouldn't, but yet when XML added namespacing it did so in a way
> that was incompatible with XML itself (see the ":" and the horrible
> set of APIs in the DOM we ended up with as a result). And when XHTML
> came along it used a namespace whereas HTML did not (we later fixed
> that).)

Yes, I said "can be added organically".  It's always possible to shoot
yourself in the foot, as XML Namespaces did, if you really try.

~TJ



Re: Are web components *seriously* not namespaced?

2015-02-05 Thread Anne van Kesteren
On Thu, Feb 5, 2015 at 2:15 AM, Tab Atkins Jr.  wrote:
> Yes, real namespacing does eventually prove necessary as the
> population grows.  That's fine.  It's something that can be added
> organically as necessary; letting everything live in the null
> namespace first doesn't harm future namespacing efforts.

(It shouldn't, but yet when XML added namespacing it did so in a way
that was incompatible with XML itself (see the ":" and the horrible
set of APIs in the DOM we ended up with as a result). And when XHTML
came along it used a namespace whereas HTML did not (we later fixed
that).)


-- 
https://annevankesteren.nl/



Re: Are web components *seriously* not namespaced?

2015-02-04 Thread Benjamin Goering
Glad to see this. I was 'checking in' on the professional practicalities of
custom elements earlier this week, and was pretty bummed when I couldn't
use XHTML5 namespaces for my employer's organization.

I build widgets all day. They run in inhospitable that websites I'm not in
control of. They have so many globals I just can't even. I get planning,
execution, and/or distribution friction when the standards prevent be from
creating a truly universal web component that will work in all those
environments.

To Tab's point, I don't think that will prevent a 90%-sufficient solution,
or one that is 99%-sufficient for some subset of the potential market.
But I do agree with Kurt that eventually it seems like 'the right way'.

It seems valuable today to at least standardize and have a spec for XHTML5
Custom Elements (e.g. ). <1% of sites will actually use
these in a way that fully validates against XHTML5. But at least web
authors and developers will be using the web instead of Contrived
JavaScript Embeds.

With a vote of confidence (or better yet spec) on the consistency of XHTML5
Custom Elements, I see no reason why I couldn't in the interim use this,
and sleep at night knowing it will eventually be the way the web actually
works:

https://html.my-vendor.com/elements";>



or

https://html.my-vendor.com/elements";>




One of the cool things about this is: Let's say in that last example I need
to switch vendors or change where in the cloud my elements come from (e.g.
QA, Staging, Production). All I need to change is the xmlns URL in that one
attribute.

Critiques?

--
Benjamin Goering - @bengo
Platform @Livefyre Labs

On Wed, Feb 4, 2015 at 5:15 PM, Tab Atkins Jr.  wrote:

> On Thu, Feb 5, 2015 at 12:00 PM, Kurt Cagle  wrote:
> > 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.
>
> Yes, real namespacing does eventually prove necessary as the
> population grows.  That's fine.  It's something that can be added
> organically as necessary; letting everything live in the null
> namespace first doesn't harm future namespacing efforts.
>
> > 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) !
>
> There are more namespacing solutions in heaven and earth, Horatio,
> than are dreamt of in your XML.  Most of them don't commit the same
> mistakes that XML namespaces did.
>
> ~TJ
>
>


Re: Are web components *seriously* not namespaced?

2015-02-04 Thread Tab Atkins Jr.
On Thu, Feb 5, 2015 at 12:00 PM, Kurt Cagle  wrote:
> 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.

Yes, real namespacing does eventually prove necessary as the
population grows.  That's fine.  It's something that can be added
organically as necessary; letting everything live in the null
namespace first doesn't harm future namespacing efforts.

> 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) !

There are more namespacing solutions in heaven and earth, Horatio,
than are dreamt of in your XML.  Most of them don't commit the same
mistakes that XML namespaces did.

~TJ



Re: Are web components *seriously* not namespaced?

2015-02-04 Thread Kurt Cagle
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
443-837-8725



On Wed, Feb 4, 2015 at 2:58 PM, Tab Atkins Jr.  wrote:

> On Thu, Feb 5, 2015 at 8:31 AM, Glen  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
>
>


Re: Are web components *seriously* not namespaced?

2015-02-04 Thread Tab Atkins Jr.
On Thu, Feb 5, 2015 at 8:31 AM, Glen  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



Re: Are web components *seriously* not namespaced?

2015-02-04 Thread Glen

Can either of you provide an example in layman's terms?

I don't quite understand what this will look like.

G.

On 2015/02/05 00:29, William Edney wrote:

Glen -

Glenn has the answer.

So we're going to come up with yet-another-registry rather than use 
one that already exists and guarantees (at least as far can be 
guaranteed) uniqueness: DNS.


The ramifications of not making HTML5 be XHTML5 will be with us for a 
very long time indeed.


Cheers,

- Bill

On Wed, Feb 4, 2015 at 3:41 PM, Dimitri Glazkov > wrote:


The proposed solution is using registries:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24578

The registry API hasn't been spec'd yet.

:DG<

On Wed, Feb 4, 2015 at 1:31 PM, Glen mailto: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.

Can someone explain why this is so, and what the justification
is? Or is it just a case of "it was too complicated, this is
good enough"?

I see this has been brought up once before @
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0964.html,
but nothing changed.

It's not going to be long before  has been defined by
1,000,000 people (slight exaggeration), and you have no idea
what it is or where it came from without looking through
imports/scripts etc. Also you want to keep things short, so
you call your element  (you work for Monkey
Solutions LLC), but then someone else on the team is importing
 from Microsoft, and BAM!, you have another problem.

Why can't we do something like this?



var panel = document.registerElement("panel", {
namespace: "ms https://monkey-solutions.com/namespace";
});




var panel = document.registerElement("panel", {
namespace: "ms https://microsoft.com/namespace";
});






https://microsoft.com/namespace"; prefix="msft" />




You could also assign a prefix to all elements within a
namespace like this:

https://microsoft.com/namespace";
prefix="msft" />

You can override the prefix multiple times and the closest
 definition is used.

Please note that the above syntax is just an example of what
could be used.

Another BIG pro here is that IDEs can pull in information
about the elements by sending an HTTP request to the namespace
URI so that a tooltip could be displayed with an element
description, author, sample usage, etc.

I really do hope that it's not too late to make such a change.

Regards,

Glen.







Re: Are web components *seriously* not namespaced?

2015-02-04 Thread William Edney
Glen -

Glenn has the answer.

So we're going to come up with yet-another-registry rather than use one
that already exists and guarantees (at least as far can be guaranteed)
uniqueness: DNS.

The ramifications of not making HTML5 be XHTML5 will be with us for a very
long time indeed.

Cheers,

- Bill

On Wed, Feb 4, 2015 at 3:41 PM, Dimitri Glazkov  wrote:

> The proposed solution is using registries:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24578
>
> The registry API hasn't been spec'd yet.
>
> :DG<
>
> On Wed, Feb 4, 2015 at 1:31 PM, Glen  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.
>>
>> Can someone explain why this is so, and what the justification is? Or is
>> it just a case of "it was too complicated, this is good enough"?
>>
>> I see this has been brought up once before @
>> http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0964.html,
>> but nothing changed.
>>
>> It's not going to be long before  has been defined by 1,000,000
>> people (slight exaggeration), and you have no idea what it is or where it
>> came from without looking through imports/scripts etc. Also you want to
>> keep things short, so you call your element  (you work for Monkey
>> Solutions LLC), but then someone else on the team is importing 
>> from Microsoft, and BAM!, you have another problem.
>>
>> Why can't we do something like this?
>>
>> 
>> 
>> var panel = document.registerElement("panel", {
>> namespace: "ms https://monkey-solutions.com/namespace";
>> });
>> 
>>
>> 
>> 
>> var panel = document.registerElement("panel", {
>> namespace: "ms https://microsoft.com/namespace";
>> });
>> 
>>
>> 
>> 
>>
>> 
>> https://microsoft.com/namespace";
>> prefix="msft" />
>>
>> 
>> 
>>
>> You could also assign a prefix to all elements within a namespace like
>> this:
>>
>> https://microsoft.com/namespace";
>> prefix="msft" />
>>
>> You can override the prefix multiple times and the closest 
>> definition is used.
>>
>> Please note that the above syntax is just an example of what could be
>> used.
>>
>> Another BIG pro here is that IDEs can pull in information about the
>> elements by sending an HTTP request to the namespace URI so that a tooltip
>> could be displayed with an element description, author, sample usage, etc.
>>
>> I really do hope that it's not too late to make such a change.
>>
>> Regards,
>>
>> Glen.
>>
>>
>


Re: Are web components *seriously* not namespaced?

2015-02-04 Thread Glen
It doesn't really matter whether or not it's based on (or at least 
resembles) XML, as long as there is some way to specify (and redefine) 
the prefix of custom elements.


G.

On 2015/02/04 23:39, Glenn Adams wrote:



On Wed, Feb 4, 2015 at 2:31 PM, Glen > 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.


There is a serious antipathy towards XML in some quarters. So I 
believe the vocabulary was designed for non-XML namespace aware 
parsers. Others can verify my understanding (or not).



Can someone explain why this is so, and what the justification is?
Or is it just a case of "it was too complicated, this is good enough"?

I see this has been brought up once before @
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0964.html,
but nothing changed.

It's not going to be long before  has been defined by
1,000,000 people (slight exaggeration), and you have no idea what
it is or where it came from without looking through
imports/scripts etc. Also you want to keep things short, so you
call your element  (you work for Monkey Solutions LLC),
but then someone else on the team is importing  from
Microsoft, and BAM!, you have another problem.

Why can't we do something like this?



var panel = document.registerElement("panel", {
namespace: "ms https://monkey-solutions.com/namespace";
});




var panel = document.registerElement("panel", {
namespace: "ms https://microsoft.com/namespace";
});






https://microsoft.com/namespace";
prefix="msft" />




You could also assign a prefix to all elements within a namespace
like this:

https://microsoft.com/namespace";
prefix="msft" />

You can override the prefix multiple times and the closest
 definition is used.

Please note that the above syntax is just an example of what could
be used.

Another BIG pro here is that IDEs can pull in information about
the elements by sending an HTTP request to the namespace URI so
that a tooltip could be displayed with an element description,
author, sample usage, etc.

I really do hope that it's not too late to make such a change.

Regards,

Glen.






Re: Are web components *seriously* not namespaced?

2015-02-04 Thread Dimitri Glazkov
The proposed solution is using registries:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24578

The registry API hasn't been spec'd yet.

:DG<

On Wed, Feb 4, 2015 at 1:31 PM, Glen  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.
>
> Can someone explain why this is so, and what the justification is? Or is
> it just a case of "it was too complicated, this is good enough"?
>
> I see this has been brought up once before @ http://lists.w3.org/Archives/
> Public/public-webapps/2013AprJun/0964.html, but nothing changed.
>
> It's not going to be long before  has been defined by 1,000,000
> people (slight exaggeration), and you have no idea what it is or where it
> came from without looking through imports/scripts etc. Also you want to
> keep things short, so you call your element  (you work for Monkey
> Solutions LLC), but then someone else on the team is importing 
> from Microsoft, and BAM!, you have another problem.
>
> Why can't we do something like this?
>
> 
> 
> var panel = document.registerElement("panel", {
> namespace: "ms https://monkey-solutions.com/namespace";
> });
> 
>
> 
> 
> var panel = document.registerElement("panel", {
> namespace: "ms https://microsoft.com/namespace";
> });
> 
>
> 
> 
>
> 
> https://microsoft.com/namespace";
> prefix="msft" />
>
> 
> 
>
> You could also assign a prefix to all elements within a namespace like
> this:
>
> https://microsoft.com/namespace";
> prefix="msft" />
>
> You can override the prefix multiple times and the closest 
> definition is used.
>
> Please note that the above syntax is just an example of what could be used.
>
> Another BIG pro here is that IDEs can pull in information about the
> elements by sending an HTTP request to the namespace URI so that a tooltip
> could be displayed with an element description, author, sample usage, etc.
>
> I really do hope that it's not too late to make such a change.
>
> Regards,
>
> Glen.
>
>


Re: Are web components *seriously* not namespaced?

2015-02-04 Thread Glenn Adams
On Wed, Feb 4, 2015 at 2:31 PM, Glen  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.
>

There is a serious antipathy towards XML in some quarters. So I believe the
vocabulary was designed for non-XML namespace aware parsers. Others can
verify my understanding (or not).


>
> Can someone explain why this is so, and what the justification is? Or is
> it just a case of "it was too complicated, this is good enough"?
>
> I see this has been brought up once before @ http://lists.w3.org/Archives/
> Public/public-webapps/2013AprJun/0964.html, but nothing changed.
>
> It's not going to be long before  has been defined by 1,000,000
> people (slight exaggeration), and you have no idea what it is or where it
> came from without looking through imports/scripts etc. Also you want to
> keep things short, so you call your element  (you work for Monkey
> Solutions LLC), but then someone else on the team is importing 
> from Microsoft, and BAM!, you have another problem.
>
> Why can't we do something like this?
>
> 
> 
> var panel = document.registerElement("panel", {
> namespace: "ms https://monkey-solutions.com/namespace";
> });
> 
>
> 
> 
> var panel = document.registerElement("panel", {
> namespace: "ms https://microsoft.com/namespace";
> });
> 
>
> 
> 
>
> 
> https://microsoft.com/namespace";
> prefix="msft" />
>
> 
> 
>
> You could also assign a prefix to all elements within a namespace like
> this:
>
> https://microsoft.com/namespace";
> prefix="msft" />
>
> You can override the prefix multiple times and the closest 
> definition is used.
>
> Please note that the above syntax is just an example of what could be used.
>
> Another BIG pro here is that IDEs can pull in information about the
> elements by sending an HTTP request to the namespace URI so that a tooltip
> could be displayed with an element description, author, sample usage, etc.
>
> I really do hope that it's not too late to make such a change.
>
> Regards,
>
> Glen.
>
>