W3C home > Mailing lists > Public > www-svg@w3.org > March 2007

Re: Scope of Progress...

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 5 Mar 2007 09:29:14 -0800
Message-Id: <0C429376-697C-4864-86AF-9F220A126761@apple.com>
Cc: web API <public-webapi@w3.org>, WAI PF public <wai-xtech@w3.org>, SVG chatter <www-svg@w3.org>, Ellen Siegel <ellen.siegel@sun.com>
To: Charles McCathieNevile <chaals@opera.com>


On Mar 4, 2007, at 8:48 PM, Charles McCathieNevile wrote:

>
> Hi, we are currently at an impasse, where I have been proposing a  
> minimal scope for progress, based on the fact taht anything that  
> can make progress has to already have some defined start and end  
> condition, and Maciej proposes that the progress events include  
> events to identify the start and end position redundantly (allowing  
> you to build widgets for progress events wherever they are found,  
> rather than building for the thing that is going to send the  
> progress events).

I think that is a somewhat misleading presentation of the  
alternatives. Most possible progress event sources dispatch the same  
error/abort/load events that I suggested incorporating as end events  
into the progress spec, so there is no actual extra event dispatch.  
Most possible progress event sources have no defined start event at  
all (the only way you know it started is you told it to start), so  
that event also would not be redundant.

>
> We need to find some intelligent way to pick between the two  
> options, since there isn't, as far as I can tell, much of a  
> compromise position that makes sense. On the other hand, if we  
> specify the "fully self-contained" approach, it is possible to  
> write the same kind of code as for the "minimalist integrate with  
> other specs" approach.
>
> I will be asking the SVG working group directly (at their meeting),  
> and other implementors, whether they consider the redundant event  
> generation to be an issue. If not, I am prepared to go with  
> Maciej's proposal. Otherwise I will write up some more detailed  
> examples of how to use the minimalist approach to write UI widgets,  
> following Maciej's example cases.
>
> Does anyone object to us making a First Public Working draft of  
> what we have now? [1]
>
> If we can resolve this issue and the other outstanding ones this  
> week, I would prefer next week to publish something as both First  
> Public Working Draft and Last Call. More or less the entire  
> discussion so far has been public, and it seems that there are only  
> a handful of people who feel strongly one way or the other about  
> these issues (although presumably resolving them per se is  
> important...). There are also implementors who would like this to  
> be resolved quickly.

I think even if the large overall issue were resolved, there would  
still be many details that need to be reviewed and worked out before  
publishing a Last Call. I think it would be a bad idea to publish  
FPWD and LC at the same time.

> Such is my plan to get some consensus on one or other approach. If  
> anyone has a better idea, or wants to make it clear that they have  
> an interest in one or other outcome that they have not yet  
> declared, now would be a good time...

Regards,
Maciej
Received on Monday, 5 March 2007 17:30:52 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:36 GMT