- From: Cullen Jennings (fluffy) <fluffy@cisco.com>
- Date: Sat, 12 Oct 2013 17:47:04 +0000
- To: Harald Alvestrand <harald@alvestrand.no>
- CC: Adam Roach <adam@nostrum.com>, "<public-webrtc@w3.org>" <public-webrtc@w3.org>
On Oct 12, 2013, at 11:33 AM, Harald Alvestrand <harald@alvestrand.no>
wrote:
> On 10/11/2013 03:40 PM, Adam Roach wrote:
>> On 10/11/13 00:09, Harald Alvestrand wrote:
>>>
>>> FWIW, the 2004 (!) version of DOMError contains the "message" field:
>>>
>>> http://www.w3.org/TR/DOM-Level-3-Core/core.html#ERROR-Interfaces-DOMError
>>
>> Apparently, I don't understand how any of this works. What I found was this less-than-a-year-old document, which defines an unusably minimal DOMError:
>>
>> http://www.w3.org/TR/dom/#interface-domerror
>>
>> In any case, if we're using objects defined elsewhere as a critical part of this spec, can we put a clear documentation citation in here please? It's very difficult to take a stab at implementing a sensible error reporting scheme when our spec obliquely says "use DOMError," which can apparently mean (at least!) three very different things.
>
> Agreed.
>
> Suggestion: we should define
>
> [Constructor(DOMString name, optional DOMString message = "")]
> interface RTCError {
> readonly attribute DOMString name;
> readonly attribute DOMString message;
> };
>
> with the comment
>
> "We intend to use DOMError as soon as there is a stable reference for DOMError that contains both the name and the message field".
>
> We should also list the "name" values we use explicitly, and note which ones are currently part of the DOM specification.
>
> It seems that given that we're publishing a W3C specification, we must reference the W3C version of the spec, not the "living spec" - Anne might be able to say what the schedule is like for that.
>
works for me
Received on Saturday, 12 October 2013 17:47:32 UTC