See also: IRC log
<trackbot> Date: 31 August 2011
<fjh> ScribeNick: ernesto_jimenez
<fjh> Identity in the Browser Workshop Report, http://www.w3.org/2011/identity-ws/report
<fjh> Paper, "Design and Implementation of a Fine-grained Resource Usage Model for the Android Platform", http://recluze.files.wordpress.com/2007/06/and-usage-nauman10.pdf
fjh: talking about identity on the browser workshop
<fjh> proposed RESOLUTION: Minutes from 24 August 2011 are approved
RESOLUTION: Minutes from 24 August 2011 are approved
AnssiK: w.r.t. the issue of side effects with the battery API
... we are following the DOM Core specification which stays silent about this topic
AnssiK: do we want to move the spec forward with a dependency on DOM Core (which is not stable yet)?
dom: we probably shouldn't ignore the feedback from browser vendors in the Geo spec about the side effects
<darobin> [is anne representing Opera on this?]
AnssiK: the issue might be punctual, we didn't receive this comment from the webkit guys when they reviewed the spec
<richt> darobin: I'm inclined to ask for further clarification from Anne.
AnssiK: other specs seem to have the same question about side effects and there doesn't seem to be a clear solution
<Zakim> darobin, you wanted to wonder if we should push this discussion to www-dom; also the initEvent question I asked
<richt> perhaps someone wants to reply and ask for that clarification from Anne on-list?
<richt> or some examples.
dom: about the question whether the next publication should be a working draft or a last call
... inclined to publish it as a working draft with a note on the side effects issue
<dom> +1 on trying to get resolution from www-dom
<trackbot> ISSUE-113 -- AddEventListener in Battery Status has side effects -- open
darobin: should we send an email to the www-dom mailing list asking about this?
<darobin> ACTION: Robin to bring ISSUE-113 to www-dom [recorded in http://www.w3.org/2011/08/31-dap-minutes.html#action01]
<trackbot> Created ACTION-448 - Bring ISSUE-113 to www-dom [on Robin Berjon - due 2011-09-07].
darobin: we could also ask questions about initBatteryStatusEvent()
<richt> darobin: It's not like someone at Opera told Anne to formally send that feedback. It's fundamental design feedback.
<fjh> robin notes cancelable and bubble can be set to true when not meaningful
<richt> we should take it in to account and check we're doing it right.
AnssiK: I would like user agents to support both
darobin: I am happy to leave it to feedback by implementors
Josh_Soref: my preference is to only use the new interface in the new spec
AnssiK: we'll have to reference DOM Core rather than DOM 3
<darobin> ACTION-448: a) add question about cancelable and bubbles in init*Event and b) usage of DOM3EV vs "DOM Core"
<trackbot> ACTION-448 Bring ISSUE-113 to www-dom notes added
AnssiK: I would like to get clarification on the position of whether using DOM3 or DOM Core because the specs are overlapping
darobin: I will ask www-dom
... do we want to publish a WD or wait for feedback?
... that way we don't have people reviewing the spec which is not updated
... we can decide next week
<fjh> note - publication of updated battery WD should be decision for next week agenda
darobin: we got some feedback from the protocols and formats WG
darobin: the first feedback is about the need to have some text with the pictures
... I personally replied there's nothing we can do about it because it's the underlying content
<dom> [I think this all relates to Josh's comments on the usability of PortableContacts as a reference]
darobin: the second point is that it's not clear what the type attribute is for
... it would be useful what the type attribute for photos is useful for
... the information would be a note, nothing normative because we don't control the content
darobin: next is feedback on API Invocation via DOM Events
<dom> do we want to keep this, though?
darobin: we didn't invent this, but I agree it's not accessible
darobin: that is something we could bring to www-dom
<darobin> ACTION-448: also mention the issue of valid auto-invocation events (these should be common across the platform anyway)
<trackbot> ACTION-448 Bring ISSUE-113 to www-dom notes added
Josh_Soref: one of the working groups is planning to propose a new way to handle "Intentional Events", maybe the web events group
... it might be a joint work with ARIA, I don't know the status
<darobin> Web Events WG's sole deliverable: Web Events 1.0: Multitouch and User-Action Events
dom: it's the Web Events WG the one that is supposed to work on these kind of events (intentional events)
... they will be working with WAI
darobin: will ask www-dom
darobin: next feedback about the example UI allows to choose which fields to pick but doesn't allow to select which users to be picked
... the suggestion was to add some checkboxes to the UI to show that a user can select which users to select
<richt> the concept in the UI mockup is the same as selecting multiple files in a file picker...but whatever
Josh_Soref: it depends on the system it might not be checkboxes (specifically for OS X it should just be selectable rows)
<richt> the spec says "and the option to select one or more contacts (as appropriate) from the user interface."
darobin: it's not about whether it should be checkboxes or not, but showing that it should be an option
richt: I'm OK with changing the UI, but the text already points that out
darobin: the rest are oversights and bugs which were already addressed, we can leave these to the editor
<fjh> this review is entered in LC tracker, LC-2547, http://www.w3.org/2006/02/lc-comments-tracker/43696/WD-contacts-api-20110616/2547
richt: yes, issues 5 and 6 from the email are already fixed and will fix 4
darobin: next thing is feedback from andreas
<fjh> new set of review comments on WebIDL
darobin: going with dictionaries should be ok
darobin: should we declare our own error objects or use existing ones?
<richt> API error handling seems like something that could benefit from over-arching guidance to all groups.
darobin: there was a post about trying
<richt> to remain consistent.
darobin: about trying to avoid creating too many error objects
<darobin> ISSUE: Should we have different Error objects for each spec, or should we go the way that Exceptions are going and only have one object
<trackbot> Created ISSUE-119 - Should we have different Error objects for each spec, or should we go the way that Exceptions are going and only have one object ; please complete additional details at http://www.w3.org/2009/dap/track/issues/119/edit .
<darobin> ISSUE-119: this influences Contacts
<trackbot> ISSUE-119 Should we have different Error objects for each spec, or should we go the way that Exceptions are going and only have one object notes added
darobin: it's probably good to keep the discussion on public-script-coord
<trackbot> ACTION-436 -- WonSuk Lee to provide an example for Permissions -- due 2011-07-27 -- CLOSED
darobin: wonsuk provided an example which hasn't had a response yet
... it should be reviewed
<darobin> ACTION Laszlo to reply to http://email@example.com
<trackbot> Created ACTION-449 - Reply to http://firstname.lastname@example.org [on Laszlo Gombos - due 2011-09-07].
Josh_Soref: I will provide feedback too
darobin: lgombos have you had time to update the WD?
lgombos: not yet, I might have it in a week or two
<AnssiK> [it may be a good practice to jslint.com any example code, even if in the tolerate * mode]
darobin: anything else on feature permissions?
<fjh> have started adding additional last call comments into last call tracker