- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 21 Mar 2012 18:06:36 -0700
- To: Robin Berjon <robin@robineko.com>
- Cc: Webapps WG <public-webapps@w3.org>
On Wed, Mar 21, 2012 at 5:28 PM, Robin Berjon <robin@robineko.com> wrote: > Hi Jonas, > > On Mar 22, 2012, at 03:41 , Jonas Sicking wrote: >> It appears that something has changed in respec which causes IndexedDB >> to no longer show the "Exceptions" section for all functions and >> attributes. IndexedDB relies on the text in the Exceptions section to >> define a lot of normative requirements which means that the spec >> currently is very ambiguous in many areas. >> >> Robin, was this an intentional change in respec? Is there an old >> version of the script anywhere that we can link to? > > Yes, this was announced to spec-prod (but presumably not everyone reads that...): > > http://lists.w3.org/Archives/Public/spec-prod/2012JanMar/0018.html > > The problem is basically that "raises" is no longer in WebIDL so I had to eventually pull it too lest I generate invalid WebIDL. > > There isn't an old version but since this is CVS presumably there's some kind of arcane syntax that makes it possible to get it. Perhaps more usefully, I'd be happy to figure out a way to still express that information but without ties to deprecated WebIDL constructs (preferably requiring minimal spec changes). > > Sorry about that, I was hoping that people would either a) have moved on from old WebIDL syntax, b) see the announcement on spec-prod, or c) notice the change and scream immediately. Suggestions for a better protocol to handle this sort of change (it's the first of its kind, but possibly not the last) are much welcome. Simply displaying a table of exceptions after the parameters list seems like it would be WebIDL compatible. I.e. we wouldn't need the 'raises' syntax inside the IDL itself, but having a separate description of the various exceptions thrown by a function seems like it could be useful. Possibly have less focus on the Exception interface-type since it's almost always going to be DOMException. / Jonas
Received on Thursday, 22 March 2012 01:07:35 UTC