W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2015

Allow partial enums in return values?

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Thu, 22 Jan 2015 14:11:29 -0500
Message-ID: <54C14B61.8050006@mozilla.com>
To: public-script-coord@w3.org
On 11/6/14 4:28 PM, bugzilla@jessica.w3.org wrote:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27048

Hi all,

There's a case in WebRTC where we've instinctively defined the webidl 
enum RTCStatsType for types of dictionaries returned from getStats(). [1]

Since these are not living documents, other specs may want to extend 
what stats a browser can return in the future - without having to update 
webrtc-stats - so the group finds itself considering reverting 
RTCStatsType to DOMString to allow for this [2].

While an argument can probably be made that this is fair, going with 
DOMString looses all the documentation and referencing benefits that 
seemed inherently good - and still seem good - about having an 
RTCStatsType in the first place. Furthermore, the reason for the 
limitation only seems to make sense in the spec space, not the 
implementation space (farewell binding code) or usage space.

A plain string looses the idea that there are special strings that have 
defined meanings.

We also lose a place for other specs to link to when they extend the 
definition, e.g. another spec might make up a string without reference.

Is there room for a construct in-between string and enum here? A partial 
enum? Other solutions?

RTCStatsType is not used as an input.

.: Jan-Ivar :.

[1] http://w3c.github.io/webrtc-stats/#idl-def-RTCStatsType
[2] https://lists.w3.org/Archives/Public/public-webrtc/2015Jan/0068.html
Received on Thursday, 22 January 2015 19:11:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:23 UTC