Review comments of Editors Draft of Progress Events

Chaals et al,
This is a response to the request that SVG WG members review the proposed draft of Progress Events, and the related emails on this list. The other review feed back on this list has been very constructive and I support the conclusion made thus far.

I the message below I suggest some editorial changes in addition to those mentioned by others, and then some comments in response to the @@issues you listed in the 1.9 draft.
 
There is no direct/explicit statement that this event interface extends DOM 3 Events. The current draft makes several assumptions that features described in DOM 3 Events can also be used, e.g. dispatching of event. Shouldn't there be a ref to DOM 3? And if so, then a reference to the document should be made as well in ref section. 
 
In the description of the example, replace: "Where the size of a download is unknown there is simply an animation." with "In the case where the size of the resource being loaded is unknown a repetitive animation is displayed."
 
initProgressEventNS description needs to make the statement that "the value of the namespaceURI argument must be null."
 
Issues noted as "@@issue" in the spec:
1) clarify conformance criteria for tools, specifications. Content?
[Andy] For tools I think its up to the host language to make those conformance criteria. Requirements for how a host language must integrate these events should follow the model of conformance statements outlined in DOM 3 Events don't you think? http://www.w3.org/TR/DOM-Level-3-Events/events.html#Conformance
 
2) should we require some firing frequency for the progress type events?
[Andy] I don't see that the benefit outweighs the cost, especially on limited resource devices.
 
3) do we need to include the headers or other overhead content to the size of the resource for which events are being triggered?
[Andy] No.
 
4) presumably this spec should be workable with non-HTTP transfers, HTTP HEAD requests, etc?
[Andy] Yes I would support that. How do you see that impacting the current spec? I don't see any impact.
 
5) How do you measure the progress of an HTTP POST where a measurable amount of data goes up, and another one comes back?
[Andy] I await finalization of the modified wording which will be forthcoming after the conclusions of the email discussions.
 
6) should we defer to the definition of initEvent instead of specifying initProgressEvent?
 [Andy] The ProgressEvent does have these additional attributes for which intiProgressEvent provides a mechanism to set. So No, don't defer but keep the initProgressEvent method.
 
Cheers,
Andy
 

________________________________________________
Andrew Sledd
Ikivo AB 
Östermalmsgatan 87 C
SE-114 59 Stockholm
Sweden
Mobile: +46 70 305  7712
Fax: +46 8 534 811 86
Email: andrew.sledd@ikivo.com
<http://www.ikivo.com/> http://www.ikivo.com <http://www.ikivo.com/> 


The information transmitted in this email and any attachment(s) is intended solely for the addressee(s) and may contain confidential, proprietary or privileged material. Any review, retransmission, dissemination, reproduction, disclosure, reliance upon or any other use of this information by persons or entities other than the intended recipient(s) is strictly prohibited. If you received this email in error, please notify the sender and delete all related material forthwith.

Received on Friday, 9 March 2007 04:00:05 UTC