Review comments of Editors Draft of Progress Events

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Review comments of Editors Draft of Progress Events

Andrew Sledd

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: [hidden email]
<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.


Reply | Threaded
Open this post in threaded view
|

Re: Review comments of Editors Draft of Progress Events

Bjoern Hoehrmann

* Andrew Sledd wrote:
>initProgressEventNS description needs to make the statement
>that "the value of the namespaceURI argument must be null."

I don't think so. The point of having the method is that this allows
others to re-use the interface for new event types, for example, for
proprietary browser extensions or for rarely used event types defined
by other organizations, neither of which should define event types in
no namespace without consulting the WebAPI Working Group.
--
Björn Höhrmann · mailto:[hidden email] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Reply | Threaded
Open this post in threaded view
|

RE: Review comments of Editors Draft of Progress Events

Andrew Sledd
In reply to this post by Andrew Sledd

Bjoern,
I of course support the use of the interface for extension and new event types, where approriately implemented. However for the event types defined in this spec it must be null, musn't it?  The current wording needs to be tightened up to signify this. Possibly additional wording in Conformance section or a new sesction to specify how extending this should be done.

Andy
-----Original Message-----
From: Bjoern Hoehrmann [mailto:[hidden email]]
Sent: den 9 mars 2007 05:09
To: Andrew Sledd
Cc: [hidden email]; [hidden email]
Subject: Re: Review comments of Editors Draft of Progress Events

* Andrew Sledd wrote:
>initProgressEventNS description needs to make the statement that "the
>value of the namespaceURI argument must be null."

I don't think so. The point of having the method is that this allows others to re-use the interface for new event types, for example, for proprietary browser extensions or for rarely used event types defined by other organizations, neither of which should define event types in no namespace without consulting the WebAPI Working Group.
--
Björn Höhrmann · mailto:[hidden email] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Reply | Threaded
Open this post in threaded view
|

Re: Review comments of Editors Draft of Progress Events

Charles McCathieNevile-2
In reply to this post by Bjoern Hoehrmann

On Fri, 09 Mar 2007 15:08:46 +1100, Bjoern Hoehrmann <[hidden email]> wrote:

>
> * Andrew Sledd wrote:
>>initProgressEventNS description needs to make the statement
>>that "the value of the namespaceURI argument must be null."
>
> I don't think so. The point of having the method is that this allows
> others to re-use the interface for new event types, for example, for
> proprietary browser extensions or for rarely used event types defined
> by other organizations, neither of which should define event types in
> no namespace without consulting the WebAPI Working Group.

But for generating the actual events defined in the spec, they should have the null namespace, right? (Which is what Andy means)

cheers

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

Reply | Threaded
Open this post in threaded view
|

Re: Review comments of Editors Draft of Progress Events

Bjoern Hoehrmann
In reply to this post by Andrew Sledd

* Andrew Sledd wrote:
>I of course support the use of the interface for extension and new event
>types, where approriately implemented. However for the event types
>defined in this spec it must be null, musn't it?

The draft defines that the pre-defined event types are in no namespace,
so yes, in order to properly initialize an event object you would pass
null. However, this has nothing to do with the definition of the method,
making the change you suggested would be similar to defining the create-
ElementNS method like so:

  ...
  namespaceURI
  ...
    * must be 'http://www.w3.org/2000/svg' for SVG elements
    * must be 'http://www.w3.org/1999/xhtml' for XHTML elements
    * ...

It would just be an incomplete and possibly confusing re-iteration of
facts that follow directly from the definitions in the specifications.
You also didn't ask that the typeArg parameter's definition notes that
it must be one of the pre-defined event type's local name.
--
Björn Höhrmann · mailto:[hidden email] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/