Re: Extensibility for constraints and registry

I would like to be able to add new names to things without waiting for a W3C spec and at the same time know that I did not reuse a string that someone else used. To be more specific, if the W3C says that people can not do that, I predict the W3C will just be ignored and it will happen anyways. There are lots of devices that port browsers to that specific environment but may have capabilities beyond the average desktop OS that are exposed in that browsers for that type of device. We want lots of devices to be able to expose their functionality via the web, they need a way to do that. As a standards guys, I recognize that all SDOs always want to say you can add anything new without their permission, but in reality this fails in the market place where people do what makes sense to expose functionality to users. SDOs can help or hinder this. 

I will note that as far as I can tell, CSS names do not wait for a spec - nor will stats as far as I can tell. Seems to be going a similar direction for stats in that there will be stats not defined in a W3C spec. It seems to me that chome has added many stats (perhaps behind a flag) well ahead of any standards on it. That seems like a good thing not something that should be forbidden. 

I'd rather prefer a registry and allowed us to make sure the names did not conflict. 

If we agree to the above principal, then we can discuss if it is better to use a WIKI or IANA. If we don't agree on the above principal, should we have the same point of view on stats?






On Nov 21, 2013, at 1:13 AM, Dominique Hazael-Massieux <dom@w3.org> wrote:

> Hi,
> 
> During the Media Capture TF F2F last week, we had a detailed discussion
> on the proposed IANA registry for registering new constraints beyond the
> ones we are defining in the Media Capture and Streams spec [1].
> 
> I argued during that discussion that the case for an external registry
> (whether hosted by IANA or using a separate mechanism) wasn't clear, and
> that it was probably premature for us to tie ourselves to this specific
> extensibility mechanism. 
> 
> Given that this was the first time that I argued this point, I was
> tasked with bringing my arguments and a concrete proposal to the list
> (ACTION-28).
> 
> Here are the points that I think make it unclear that an external
> registry for constraints is warranted:
> * adding a constraint requires interoperable support from browsers;
> while we could build a process to make this a requisite of final
> registration in the IANA registry, we would likely reinvent an existing
> process made exactly to ensure interoperable support among browsers: the
> W3C process
> 
> * while coming up with a name is easy, ensuring that a given constraint
> fits the spec model (which we're still struggling with) requires time,
> expertise and consensus; this group seems like a better fit for such a
> review than a TBD-expert. The frequently used example of "3d camera" as
> a constraint illustrates this: it's not clear to me that a constraint
> would be the right approach to handle 3d cameras, since what you would
> want to get out of it is probably very different from a video stream;
> figuring out the model of how to extend getUserMedia to new use cases
> should be made thoughtfully, esp. as we have so little experience with
> it at this time.
> 
> * looked from a few steps back, any W3C spec is in fine a registry of
> names that has special meaning (HTML is a registry of element and
> attribute names, CSS a registry of CSS properties, values, JavaScript
> APIs are a registry of method, attribute, interface names, etc); the
> fact that we have something that looks like a registry (a list of
> constraint names) should not automatically make us think of IANA as the
> right place, and moving something out of W3C into IANA hands should come
> with specific reasons
> 
> I heard the following possible reasons for going to IANA rather than W3C
> for registering constraints:
> * registration in IANA can be fast (if the attached process if quick);
> but I think given the interop impact of constraints, fast is probably
> not the most important parameter for that registry; while the W3C
> process is never a matter of days, specs that define small things (e.g.
> hiresdomtimestamp) can reach rec in a matter of a few months
> 
> * IANA is here forever, this group (and/or W3C) is not; I would think
> that W3C will probably be needed (and thus exists) as long as IANA;
> whether this particular group exists or not, W3C has a well-known
> process for restarting groups if and when needed; if there is indeed a
> need of defining interoperable constraints for getUserMedia, I see no
> reason to doubt W3C would get such a group started. If for any reason
> this is not possible, I see no reason why W3C could not then point
> people to an external registry that would be emerge out of that
> unfulfilled need (and in fact, even if it didn't, presumably the lack of
> pointer would have no effect on actual interoperability assuming such a
> registry is built with support from implementors)
> 
> * constraint names might be reused beyond the W3C spec (e.g. at the
> protocol layer), in which case having a W3C-independent registry would
> make sense; that might (or might not) be true, but given that we don't
> have such a case at this time, it doesn't seem like this should be part
> of our decision.
> 
> Overall, I can imagine that once we have experience with extending
> getUserMedia (with constraints and other mechanisms), we realize that
> there are cases where a IANA registry, a wiki page, or another
> registry-based extensibility mechanism will be useful. But I think we
> have way too little experience at this point to commit ourselves to any
> such process, and I don't think we'll get such experience before the
> first version of the core spec finishes its standardization process.
> 
> My concrete proposal to replace what is currently in the spec would be
> thus:
> * remove the IANA registry registration from the spec
> * remove mentions of the registry in the spec
> * add a note to implementors in the spec encouraging them to bring
> proposals of new constraints to this group, and to not make new
> constraints available publicly (i.e. without a flag) until two
> independent implementations of such a constraint have surfaced
> (mimicking the CSS WG policy)
> 
> Dom
> 
> 1. http://www.w3.org/2013/11/14-mediacap-minutes.html#item07
> 
> 
>

Received on Tuesday, 26 November 2013 00:17:38 UTC