name space reservation / confirmation

I see the site / community has had explosive growth (which is awesome!). I’m wondering if there’s a simple way of effectively registering who has authority over certain name spaces of elements registered there though. This is not meant to be a gate keeper system but to avoid potential security and brand / legal conflicts.

For example:

• google-youtube : Very obviously an element for talking to youtube, this happens to be made by Google. Awesome
• google-youtube-uploader : again, obvious what’s happening here
• nothing stops me from making a google-youtube-uploader-theme which seemingly would imply by name space that it is both affiliated with google and youtube.

Yes, the site has ways of looking and seeing “oh, that’s btopro and obviously not official” but I could see issues with allowing anyone to submit things in the name of a google name space (I could make a microsoft-bing plugin and effectively block them from getting the name space on a site w/ high visibility to promote their service integrations).

Another issue that’s less brand oriented and instead spec oriented: Polymer team has made iron elements / more periodic table focused components. These are things like iron-button, iron-ajax, neon-animation etc. However, there’s already a bunch of iron-whatever elements out there not created by the polymer team. On the surface, whatever, not an issue, but from a mental model perspective, these other iron elements aren’t actually root / atomic elements. It breaks the mental model from a development perspective but also starts to look a little weird when a whole bunch of low quality “iron” elements are going to bubble up in the same name space as high quality ones.

I’m a lead dev on the lrn / lrnwebcomponents series of elements, so I’m just curious what the community feeling is on this potential issue. Our lrn components have 0 design implication (by design) while they all implement our lrndesign elements (which could be used anywhere). If anyone produced lrn elements without any form of approval and not matching this model it could basically create all kind of name-spaced elements in the lrn universe that i now have to avoid from a naming convention aspect as well as in promoting what’s part of the official portfolio of elements. I imagine the vaadin team would have a similar concern if people starting building vaadin components that aren’t actually vaadin.

Someone at a meeting asked about name spacing / how to avoid collisions as your app gets more and more complex and I didn’t actually have a good answer so that’s what kicked off this thought.

[samuelli]

A lot to process here so my thought might be a bit scrambled at this stage.

A bunch of relevant features/properties of the existing publishing model:

• Multiple elements of the same name can be published given that all repos are scoped by the author.
• Collections, IMO, are a nice way to achieve an ‘official’ grouping mechanism. ie. you could accept components from others after going through some approval process.
• For the Polymer team collections, I see this as a really strong mechanism to encourage the community to fill the gaps in a collection. Searching for “iron-” I don’t really see any issues - its easy to identify who made what but I still get a sense they’re loosely grouped.

Questions:

• What is the exact concern here? That others might publish something lrn-*, its low quality, and users are not able to identify that it doesn’t belong with the rest?

Current thoughts:

• Generally speaking, I’ve aimed to keep wc.org as open as possible and keep complexity out as much as possible since its still a relatively small community still.
• I hope that the community eventually makes the switch to NPM, which has scopes. eg. @lrn/some-element.
• Any namespace system gets messy with someone who might be able to snatch up valuable names quicker than others and then requires a resolution process.

[samuelli]

Yes, this was one of two concerns why I had this issue (and saw it already existed). Another benefit is that you could see from required meta information in a namespace registry what project a component is related to because e.g. multiple authors could do multiple projects together …

Any namespace system? How about existing ones like yourdomain.tld (with an existing, well defined resolution process) ?

The key difference is that as a free, open source community, I don’t think we have the means to effectively maintain any resolution process.

Generally, the design approach we’ve taken for webcomponents.org is to leverage existing platforms to keep things minimal and push features back onto those platforms. GitHub is the main one right now so I would recommend using GitHub organisations to scope your components.

• allow for multiple contributors
• scope components under that name
• existing approach; most collections are from these orgs.

@btopro mentioned that there may be issues distinguishing ‘official’ elements. Definitely let me know if there’s more we can do in that respect.

My second recommendation is to leverage the collections feature. With this, the collection owner/s can moderate the list of components that fit together (again via GitHub).

Thirdly, as mentioned above, my hope is that we’ll be able to move towards NPM. With that, I’d recommend taking up scopes which suit your needs and NPM has their own resolution process.

I’m going to close this issue as a) we don’t have the capacity to design & implement a full namespace system and b) there’s some alternatives (perhaps to a lesser extent. Feel free to continue to comment with suggestions or file separate issues on how we can better manage namespace related concerns, without implementing a full system.