Re: New Progress Events spec

On Thu, 08 Mar 2007 06:17:14 +1100, Ian Hickson <ian@hixie.ch> wrote:

> On Wed, 7 Mar 2007, Charles McCathieNevile wrote:

>> > I think the event 'progressError' should be 'error' for backwards
>> > compatibility.
...
>> The spec doesn't mention 'error' or 'abort', but the ways to arrive at
>> various end states are indeed not clearly distinguished.
>
> Sorry, s/error/progressError/, s/abort/progressCanceled/, and
> s/load/progressComplete/ in the above comments; I was assuming the earlier
> changes were accepted by the time I got to that comment. :-)

OK. I'll stop being small-minded ;) (Those changes are in the new draft, BTW).

>> > The spec says that the events must be cancelable but does not define
>> > their default action.
>>
>> Right. Do you have a suggestion for a default action? Is there a reason
>> we need one for everybody to implement?
>
> If there isn't one, it should just say so.

Right, that works for me.

>> > The following requirement both abuses RFC2119 terminology and makes no
>> > sense from a conformance point of view: "This method may only be
>> > called before the progress event has been dispatched via the
>> > dispatchEvent method, though it may be called multiple times during
>> > that phase if necessary."
>>
>> Could you explain what you mean by "makes no sense"?
>
> "may only" is not RFC2119-compatible grammar.

Yep.

> It also doesn't really make much sense to give conformance requirments on
> when a method call can be called. It's not formally checkable, and we have
> to define what happens when the requirement is violated anyway.

So I am not sure what the use case is for the restriction, actually. I will try to find out, because I don't see what it achieves and will otherwise remove it.

cheers

Chaals


-- 
  Charles McCathieNevile, Opera Software: Standards Group
  hablo español  -  je parle français  -  jeg lærer norsk
chaals@opera.com          Try Opera 9.1     http://opera.com

Received on Wednesday, 7 March 2007 21:56:30 UTC