Re: Please confirm DAP comment resolution

Anne

Much thanks for taking the time to clarify - it wasn't clear to me from your original comment what you meant.

(1) duplication

I see now, we have a section in the Proximity Editors Draft [1]  that defines the attributes, types and gives the definitions (5.2.1) and then this is repeated in the init section (5.2.2). 
This makes it less clear and also opens the chance for the two sections to be inconsistent. 

Here is a proposed change (no formatting, text):

[[
5.2.1 Attributes

min of type double, readonly

Definition: The maximum sensing distance

Initialization: When the object created must be initialized to positive infinity

....

For each attribute, the DeviceProximityEvent interface MUST return the value the attribute was initialized to.

When the user agent is required
...

]]


(2) queuing and firing

I thought the queueing and firing update was applied to both Proximity and Ambient Light  drafts, e.g. the updated language is 

"When a user agent is required to fire a device proximity event, the user agent must run the following steps:"
...
"When the current device proximity changes, the user agent must queue a task to fire a device proximity event at the Window object."

(3) window object

I notice our vibration interface is on 'Navigator', as is Network Information and Battery.

Everyone, any reason Proximity and Ambient Light shouldn't also be with  'Navigator', as neither is window specific?

e.g.

partial interface Navigator { 
             attribute EventHandler ondevicelight;


etc


regards, Frederick

Frederick Hirsch
Nokia

[1] https://dvcs.w3.org/hg/dap/raw-file/tip/proximity/Overview.html

On Jan 19, 2013, at 4:28 AM, ext Anne van Kesteren wrote:

> On Tue, Jan 15, 2013 at 11:27 PM,  <Frederick.Hirsch@nokia.com> wrote:
>> (1b) LC-2731 [2] ; re-order requirement for queuing and firing (I did not see other specific issues in published draft noted in the email, e.g. RFC terms in Notes or duplicate definitions)
> 
> Duplicate definitions is still there and is still as confusing as
> before. E.g. 5.2.1 lists attributes but 5.2.2 defines them. 5.2.2 also
> lists dictionary members while it is customary for EventInit derived
> dictionaries to not be listed as such at all, they only need to be in
> the IDL fragment.
> 
> 
>> (2b) LC-2737 [4] , re-order requirement for queuing and firing (I did not see other specific issues in published draft noted in the email, e.g. RFC terms in Notes or duplicate definitions)
> 
> The same problem exists in this specification.
> 
> 
> In addition, "the Window object" should probably be something else.
> There can be a whole lot of Window objects.
> 
> 
> -- 
> http://annevankesteren.nl/

Received on Tuesday, 22 January 2013 19:34:30 UTC