See also: IRC log
<trackbot> Date: 10 July 2012
<fjh> Meeting: Device APIs Working Group Face-Face 10-12 July 2012, Burlington MA
<scribe> Scribe: Josh_Soref
Fjh: restrooms are outside
... There's a cafeteria down the hall
... We should use it
James: James Hawkins
... At Google
... I'm interested in WebIntents
Dsr: Dave Raggett
... I'm measured on recommendations per minute
jgiraud: Jerome Giraud
... Global interest apis
Milan: Milan Patel
... Standards, W3C is in my area
... Within DAP, WebIntents are my main interest
Cathy: Cathy Chan, Nokia
Lgombos: Laszlo Gombos
Richt: Richard Tibbet
<Paul_Kinlan> Paul_Kinlan is joining now, just need to find a room
Richt: I lead extensions and
... Interested in WebIntents
... And sensors
<darobin> ScribeNick: richt
<scribe> ScribeNick: richt
Josh_Soref: Josh Soref
... interested in web intents.
fjh: Frederick Hirsch, Nokia, co-chairing this WG, interested in everything in this group
darobin: Robin Berjon
<darobin> youenn: Youenn Fablet
darobin: co-chairing with Frederick and interested in everything.
<youenn> youenn: Youenn Fablet, Canon, interested in Web Intents and media capture API
kensaku: Kensaku Komatsu
... interested in Web Intents
Naoyuki Sato, Sony
<fjh> interested in combination of web with home networks
(not on IRC)
<fjh> hiroyuki aizu
... interest is in Web Intents / integration of home network / cloud services.
<jun> Jun Fujisawa
<darobin> jun: Jun Fujisawa, Canon
aizu: interested in 2 things:
inter-device communication based on e.g. Web Intents. Printing
from camera or displaying camera content on TV.
... second interest: an advanced media capture API. A Camera API.
... Canon hope to officially be a member of DAP shortly. Currently attending as an observer.
dcheng3: Diana Cheng,
... interested in Web Intents, Network Information API, Sensors.
... main interest in Web Intents.
Wonsuk: Wonsuk Lee, Samsung
... participate in Tizen group. Samsung interested in all of the Device APIs.
... Contact and Calendar APIs are particularly important to us.
Tizen wants to bring more advanced APIs to the web for richer experiences.
<darobin> Jungkee: Jungkee Song
scribe: Working on Tizen as well. Working on Gallery API based on Web Intents. Interested in additional Web Intents-based APIs.
nwidell: Niklas Widell
... interest in Web Intents, Sensor APIs and Capture parts.
Paul_Kinlan: Paul Kinlan,
... primarily interested in Web Intents.
<darobin> Giri Mandyam, Qualcomm
(not on IRC)
<darobin> "We have particular interest in the work of the Media Capture Task Force, and will also be very interested in the progress of other specifications such as the Network Info API and Web Intents."
<shan> s/... main interest in Web Intents./shan: Soonbo Han, LG Electronics, main interest is Web Intents/
[fjh runs through the proposed meeting agenda]
fjh: Any suggestions on the agenda just ping me offline.
<shan> +Present Soonbo_Han
fjh: Welcome to all new members of the working group.
<darobin> ACTION: dsr to check out why chairs got an email to announce Sony joining group but they're not listed in DBWG [recorded in http://www.w3.org/2012/07/10-dap-minutes.html#action01]
<trackbot> Created ACTION-548 - Check out why chairs got an email to announce Sony joining group but they're not listed in DBWG [on Dave Raggett - due 2012-07-17].
<scribe> ScribeNick: Josh_Soref
<fjh> Approve minutes from 27 June
<fjh> proposed RESOLUTION: Minutes from 27 June 2012 are approved
RESOLUTION: Minutes from 27 June 2012 are approved
fjh: we have a draft
... i did a CfC
... no one complained
... i believe Anssi was supportive
... we have a 4 week LC
... there's a 3 week minimum
<fjh> CfC for Last Call: http://lists.w3.org/Archives/Public/public-device-apis/2012Jul/0005.html
<fjh> proposed RESOLUTION: publish HTML Media Capture as Last Call on 12 July 2012 with
<fjh> four week Last Call period ending 9 August 2012.
richt: how are we on implementation?
darobin: we have roughly 2 not
... we might go to CR w/ things AT-RISK
... the HTML INPUT Element extension
... we don't have fully interoperable implementations
... there's a lot of interest in implementing this
... i get the sense from browser implementers that they don't care about the syntax
... everyone says we don't care what it looks
... there's pressure from CoreMob
... dear-dap please ship it
richt: theory should be document current practice
dsr: plh is keen for us as we go
... to get feedback from the HTML WG
darobin: the only feedback from the HTML WG would be "this should be in our spec"
<darobin> [I note that that was a jocular comment]
[ Scribe notes that the HTML WG expressed some interest in California in not owning everything ]
RESOLUTION: publish HTML Media Capture as Last Call on 12 July 2012 with four week Last Call period ending 9 August 2012.
<fjh> Battery in CR http://dvcs.w3.org/hg/dap/raw-file/tip/battery/CR.html ;
<fjh> open actions to produce test cases; ACTION-522, ACTION-523 able to exit CR after 1 July.
fjh: Battery is in CR
<trackbot> ACTION-522 -- Robin Berjon to write tests for Battery -- due 2012-03-28 -- OPEN
darobin: Battery is in CR
... i haven't finished updating the testsuite yet
... i'm still updating it
... i hoped to finish by this meeting
... those actions are still open
... i'm making progress
... i hope to exit CR by end of summer
... we have implementations
... a good spec
... half of a test suite
... it all looks good to me
fjh: Anssi will be back
darobin: yes, that will help as well
<fjh> plan is to exit CR at end of summer assuming all goes well
<fjh> Vibration in CR http://www.w3.org/TR/2012/CR-vibration-20120508/ ;
<fjh> open actions to produce test cases; ACTION-523 able to exit CR after 1 July
fjh: i think this is similar to Battery
darobin: i have an action on this from the Test Infrastructure Group
fjh: not CoreMob
<fjh> Proximity - latest editors draft , http://dvcs.w3.org/hg/dap/raw-file/tip/proximity/Overview.html
... i believe you were interested in talking about it
Josh_Soref: I doubt it was Paul_Kinlan
<Paul_Kinlan> It wasn't me
<fjh> proposed ACTION fjh to prepare CfC to publish FPWD of Proximity API specification
darobin: i think it was dougt
... is there any objection to publishing a FPWD?
... a FPWD is an indication of progress
... it isn't a commitment to the document as is
... if there are minor questions/comments
... we can either incorporate them
... or into the next draft
PROPOSED RESOLUTION: WG agrees to publish a FPWD of Proximity API specification
fjh: we don't need a short name, do we?
darobin: i think we do
dsr: yes, you do
fjh: we have Proximity in our
... i think that's fine
RESOLUTION: Short name for Proximity API will be "Proximity"
fjh: that's the thing people always forget, is the short name
RESOLUTION: WG agrees to publish a FPWD of Proximity API specification with short name "Proximity"
<fjh> ACTION: rberjon to prepare CfC to publish FPWD of Proximity API [recorded in http://www.w3.org/2012/07/10-dap-minutes.html#action02]
<trackbot> Created ACTION-549 - Prepare CfC to publish FPWD of Proximity API [on Robin Berjon - due 2012-07-17].
fjh: we have a FPWD
... we have an ED w/ updates
... we have some issues in the Wiki
... jhawkins, you have some updates?
jhawkins: we're really excited
... congratulations everyone for helping put that together
... the biggest part was the last F2F in Shenzhen
... wrt the Chrome implementation, we've been working w/ UX to address the bad UI we have
... we're hashing out what the UI will look like
... right now, the feedback we've got from developers
... was that they like the API, but they can't ship if the UI is bad
darobin: do you know when this will be present?
jhawkins: I think this could
appear in Chrome 22
... we deprioritize working w/ clients of the API
... we have a list of changes we want
... some dating back to the F2F
... they're nice to haves
... perhaps something we could be productive on here
... we did a presentation two weeks ago @Google.IO
... it was really exciting
... of all the presentations I attended, it had the longest Q/A session
... we had hallway presentations about it
... we did a Code Lab with 40 developers
... doing a hands on tutorial for writing web intents
... we found a ton of bugs this way
... it was good to get that feedback
jhawkins: we need to find a way
for people to be hands on
... writing demo code
... to tease out some of these bugs
... mounir posted the WebActivities counter-proposal
... we could go over them today?
... I think there are some Issues?
fjh: we could go over Explicit
... i think it's sparse in the spec
jhawkins: that's a good
... the spec has gotten really dense
... after reading it so many times, it's hard to find bugs
... that's a plea for editing help w/ the spec
fjh: are there issues we haven't
talked through/thought about?
... i think there are more implications
jhawkins: certainly security/privacy
fjh: my concern with Explicit intents is that it defeats the paradigm
jhawkins: the way we rationalize
... in our UI, the user can choose in the picker
... it's like a client default
... but the user can go back and pick another service
fjh: so if you're doing photos,
and you do an editor thing
... you'd land in the editor, and you could go back?
jhawkins: say inline
... you'd have a link to go back
... [in the UA]
... also for the window disposition
... if you know the popup blocker alert
... in chrome, it's a box on the top right
... we'd have a bar like that which would let the user to pick other things
fjh: the client would set the
... all clients could do this normally
... and users could do this path
... there's a privacy risk where data is sent on that fast path
... and the receiving side sees it
... without the user being able to prevent that
jhawkins: that's a concern
fjh: it seems people would maybe choose to do that more often
Paul_Kinlan: if you're building
an application with an image editor
... with crop, red-eye removal
... you might build each component using intents
... you make those small components available for external clients
... but you use it for your main app
fjh: sort of like a manifest for
... sort of a different UC
dsr: if it's Same-Origin, then that's less of an issue
fjh: i forgot if that section
talks about origin
... for explicit intents
jhawkins: this leaves out the
possibility of a webintents agent
... you can do that w/ explicit intents
... it could be a picker itself
... we'd lose it if we leave out explicit
... i understand we could be sending out data w/o knowing where it's going
fjh: it seems like we have a
great model where we have a user mediated stage
... explicit intents lets you bypass the whole thing
<fjh> josh_soref: could change explicit intent mechanism to open connection, load page, but not share data initially
<fjh> jhawkins: this is a possibility
jhawkins: i'd like to point to how Android Intents worked
<jhawkins> Explicit intents designate the target component by its name (the component name field, mentioned earlier, has a value set). Since component names would generally not be known to developers of other applications, explicit intents are typically used for application-internal messages — such as an activity starting a subordinate service or launching a sister activity.
<fjh> not security by obscurity though
Josh_Soref: it sounds like this argues for same-origin
jhawkins: if we have a solution
for privacy that are compelling
... the notion of a web-intents Agent
... we've heard it from other people
Jungkee: i have a UC for Gallery
... we can avoid interaction with explicit intents
... they can just go directly to the service
... like local storage
... an service provider provides explicit service
... and the user doesn't have to pick something
fjh: why wouldn't you want User
... i don't understand why you'd want that
Jungkee: with explicit, you don't show a picker
fjh: but why wouldn't you want to show the picker?
Jungkee: because the user has to
choose the picker before picking the media
... we can give a better UX
fjh: it seems like you're worried
about repeated interactions
... you're talking about wanting to remember previous options
... i thought there already was a way to do that without explicit intents
jhawkins: that's correct
Jungkee: if a service provider provides explicit urls
richt: we've also looked at this
... it isn't just an issue for web intents
... one solution is accountability through transparency
... we give users/developers the ability to look through data through logs
... that's an informal kind of contract
... it helps
... you can't just push through crazy stuff w/o accountability
... if you do stuff with dev tools
... i think that'll be a factor in trying to solve privacy issues
jhawkins: this came up about 2
... there's an extension in the Chrome Web Store
... it's the Web Intents Debugger
... we want to take that concept and move it into the Web Inspector
... so yeah, we're on the same page with that
richt: there is a way of
highlighting and putting pressure on companies to not do stupid
... if you need to keep your reputation in tact
... it's a way to do this
fjh: not sure how to do that
jhawkins: best practices
... does the speed bump on privacy data address your privacy concerns?
fjh: not sure i remember the speed bump
jhawkins: it shows the destination and gives an explanation
fjh: i think so
Paul_Kinlan: on explicit
... we have one relatively big news agency partner
... they want to use explicit intents
... they have twitter, facebook, and other
... they'd like to use the same API for talking to all three sets
... but they'd like to make the actions clear
... but these partners want to have the ability to give the user a seemless experience
... but also give the intents picker
... there are people who are actively looking to use web intents throughout their whole experience
fjh: would that work with the speedbump idea?
Paul_Kinlan: i think it's kind of
... i don't think it works right now
<Zakim> Josh_Soref, you wanted to say this sounds like a need for persisted conections to intents
Paul_Kinlan: i think we need delayed delivery
<fjh> josh_soref: agree with frederick, if client makes request to use intent, user agent can persist future requests without repeated picker
<fjh> josh_soref: this could apply to speed bump case as well
<fjh> josh_soref: also gallery
<fjh> josh_soref: thus do not need explicit intent for the gallery use case
richt: the way android intents
work, if i set a default intent, it will always use that
... if i then open another provider for that intent
... then the next time i try to trigger that intent
... i'll get the picker
fjh: that makes sense
<Zakim> dsr, you wanted to note that direct binding of app to a component can be done without web intents, so using an explicit intent is presumably to allow user to pick an alternative
Josh_Soref: it's dangerous with spammers, but mostly makes sense
dsr: what's the benefit of using
web intents rather than directly
... how do you explain the benefits of using explicit intents
... and the benefit is letting users change their mind
... the benefits are same-origin
... being able to change their mind is still useful
... and for separate origin, there's a different benefit
... we should clarify the benefit
jhawkins: today on the web, it
sucks, there's one-one
... intents solves by providing one-to-n
... but we can give them this api which lets them still use one-one
... to emphasize what Paul_Kinlan was saying about a News sight
... feedback from someone AddThis
... is that users won't click on Share buttons unless they see a familiar icon
... they'll even click the share button that isn't facebook-twitter if they see facebook-twitter nearby
... doing this makes the migration path easier
... it removes the burden of using multiple apis
... 2. moving to the semantic web
... with schema.org we have nouns
... with intents, we have verbs
... if you can call the web a search engine, say you're bing
... you can understand which pages are nouns and which are verbs
... you could have the engine put these things together
... bing could put the player together in the front page
... that requires explicit intents
<Zakim> fjh, you wanted to ask whether users understand components of app and can change minds
fjh: it seems like plugging in a
random component isn't something the user would be able to fit
... it seems likelihood of it working is low
... it makes sense
... but nothing prevents abuse
jhawkins: is it easier?
... you'd have to find something that works somewhere on the web
... maybe we shouldn't gloss over the problem
... using intents to structure your app into components
... maybe it is compelling, maybe it isn't
... it seems to be for android
... maybe we make it special for same-origin-explicit to skip the speed bump
... i'm a little concerned about it
fjh: we got the speed bump, and same-origin
Josh_Soref: should we action jhawkins
<fjh> josh_soref: have mail web client which has address book with explclit intent to use that address book
<fjh> ... but I want to use anther book, so first see nothing much, then want to get to other book
<fjh> ... so even with same origin want to go to different address book
<fjh> ... next time get my preferred, not same origin
<Zakim> Josh_Soref, you wanted to say that the web intent inspector matches a requirement i listed a while ago
dsr: the benefit of same-origin is avoid the speed bump
Josh_Soref: but allow for a U-turn
<fjh> u-turn is going back from explicit choice to pick after all
<fjh> josh_soref: pleased that people are realizing my previous ideas were good
Paul_Kinlan: for explicit
... web intents are typically gated on user actions
... providing a modifier like a shift key to bring up the picker
... so that the user can ask in advance to get the picker
fjh: so if i shift click on a twitter button, i get the picker?
Paul_Kinlan: a u-turn might be a
... it might be written in a way to encourage the UA to provide a way to map back to choosing
richt: it's analogous to Open/Open-With
Paul_Kinlan: it could be a
... where they say never allow explicit intent
fjh: that's something we could record in how the spec works
Josh_Soref: it's basically UA Implementer guidelines
<dsr> (fjh: e.g. a right click for the context menu with a entry for the picker)
fjh: the concern is that the more complexity you add, the more testing
jhawkins: i'm concerned that we
should try to solve it some other way
... i'd like to solve shift click
fjh: because the client didn't provide the picker
jhawkins: you don't know that there will be an intent
Josh_Soref: i think U-turn and remembering the choice is the way
jhawkins: i'd like to keep
... i think we've solved it otherwise
... but a UA can still do something like it if it likes
richt: have you looked at
... we could use the context menu, did you look at it
... having open with with a pop out menu list
jhawkins: we haven't thought
about exactly that
... we've thought about those lines
... one way is to make the browser involved
... like right clicking an image
... and start adding these integration points throughout the browser
... and also services, picking files
... exposing services where you have a button that will call start activity
... being able to right click and select something
... unless you have <button intent=>
... if you have that, i think so
richt: i think that's compelling
jhawkins: say you're in windows
and do shift-right-click
... that's more about content
... than where the client is calling start activity
... in a page
... we've talked about declarative invocation of intents
... we could do that at some point
[ Break ]
fjh: 10 minute break and then Lunch
... w3.org namespacing for intents
... web activities
jhawkins: the proposal is to move the namespace to W3.org
<jhawkins> W3.org proposal for namespacing:
<jhawkins> ACTION: http://www.w3.org/ns/intent#edit [recorded in http://www.w3.org/2012/07/10-dap-minutes.html#action03]
<trackbot> Sorry, bad ACTION syntax
<jhawkins> type: http://www.w3.org/ns/intent#image
dsr: there was a proposal on W3
... which i'll forward to the DAP ML
jhawkins: if we could drop the
'www.' and make it shorter
... it's 28 characters vs. 22 for webintents
jhawkins: it's 24 characters if
we drop www.
... 'ns/' isn't self documenting and should be removed
darobin: this is 'ns/' because it
piggy backs on the namespace for xml
... there's no reason it isn't used for other name spaces
<darobin> @prefix wi: <http://www.w3.org/ns/intent#>
<darobin> wi:edit a wi:Action
<darobin> wi:pick a wi:Action
<darobin> wi:image a wi:Type
<darobin> wi:contact a wi:Type
darobin: they're awkward and we should drop it
Josh_Soref: we all know browse
vendors hate XML and we should do everytthing to avoid any
resemblance to XML
... I don't like ns/
fjh: I don't like it either
richt: I don't either
darobin: for xml ns, it used to
be first come first serve
... come up w/ whatever you like
... then someone decided it should be coherent, with a dated namespace
... so we picked years
... so then you had to use 5 years for 5 different xml portions
... then we had pushback to use ns/ instead of random years
... i think we only managed one xml spec in ns/ (widgets -- "very successful")
... we should avoid the clustermess of xml
fjh: the goal is to avoid 'ns/' after '.org/'
Paul_Kinlan: could we have 'intent' as the subdomain?
darobin: that's asking a lot
<fjh> that would make sense: intent.w3.org
Paul_Kinlan: one goal of webintents.org was to have as little after the / as possible
<darobin> [we could just keep webintents.org...]
Paul_Kinlan: using a domain to split things off would be better
jhawkins: there's "action" and
"type" and i don't think we should do anything with type
... we're doing type everywhere else
... we already have mime types and schema.org
... are we duplicating schema.org?
... that page would have to have documentation on the type
darobin: it depends on the
... reusing schema.org for contacts doesn't work
... schema.org has different types for people and companies
jhawkins: that's a good point
Paul_Kinlan: from what jhawkins
... schema.org didn't exist
... when we looked at webintents.org
... we could have subtypes / arbitrary strinngs
... we have microformats
... there are activity streams
... i don't know that we need to manage it on w3c
jhawkins: for apis we're
... it's important to control the actual type
... "image" as a type shouldn't be specified by w3
... contact makes sense
... since we need it for the api
... having the documentation at the same place is useful
... i recant for certain explicit cases
darobin: this is for w3 WGs
... not for everyone
... if w3c manages all types, then we don't need the long types
jhawkins: that works for me too
dsr: there may be some pushback
<jhawkins> http://intents.w3.org/share -- perhaps
darobin: one of the things that
... we have actions using webintents.org
... we could just use webintents.org and make it policy
jhawkins: there was concern about
hosting+ownership of the domain
... which we could relinquish
darobin: there is an ownership issue
fjh: and also branding
jhawkins: i don't think breaking
existing deployments is a big concern
... i think it's ok to change it ONCE and never again
Paul_Kinlan: it's not like we're breaking apps, just reducing discovery
jhawkins: it's just string matching
Paul_Kinlan: i agree we should
... the ecosystem is small enough to be able to do it
richt: i know this was feedback
... how do actions resolve?
<richt> how do Web Intent actions resolve? e.g. "//w3.org:80/ns/intent?foo#image"? Or, a simpler more probable example: if the action is defined as "http://w3.org/ns/intent#image" and in my web app I use "http://www.w3.org/ns/intent#image" from memory. What happens here?
richt: we've seen this problem w/ XML NS
Josh_Soref: intent.w3.org v. intents.w3.org is this same risk problem
jhawkins: this avoids the w3 / www thing
Josh_Soref: this doesn't solve https: / http: problem
darobin: it's http:
richt: that's proved very bad in
... what about a trailing / ?
darobin: when you get it wrong, nothing happens, you immediately know your code is broken
<fjh> josh_soref: we can make things fail more and better
<fjh> josh_soref: we should make failures clear and obvious
<fjh> s/we can make things.*//
s|s/we can make things.*//|
s|josh_soref: we can make things fail more and better||
richt: why not use WI:foo ?
Josh_Soref: we tried that w/ widget: it failed
Paul_Kinlan: the goal was discoverability
<richt> WI:foo does not have the ambiguity of URLS
Paul_Kinlan: android uses reverse dns
Paul_Kinlan: they do have shortened prefixes
<richt> WI: itself could resolve to a well-defined URL.
Paul_Kinlan: we had a short-form
in the spec
... it was a convenience thing
... we got pushback from WebApps or WhatWG
... it was in our initial vision
... i was talking about a property in the Intent objct
scribe: which maps back to the string
jhawkins: sounds like we're
solving the wrong problem
... it sounds like a lot of hand-waiving
<fjh> josh_soref: failure , three examples with implementations, with different action URLs, will get separate pick lists, problem when people copy source from others
jhawkins: i'm going to put $1000 saying that this problem won't happen
darobin: to be clear, it isn't ok for the problem to be created by people in this room
<darobin> close action-549
<trackbot> ACTION-549 Prepare CfC to publish FPWD of Proximity API closed
Josh_Soref: we could ask w3 to force trailing slashes to 404
fjh: richt was asking about forcing resolvability
Josh_Soref: resolving and forcing
was a disaster for RSS
... each time netscape.com was rearranged because it was bought out
... half the RSS readers in the world broke because they relied on that NS document which 404d
<richt> ...and I'll take James's $1000 :)
Josh_Soref: richt and intents. :)
dsr: it seems like a job for W3 to be responsible to fail with a useful warning for <https> and </>
<dsr> (resolving the w3.org URI for an intent should indicate the registered string even if uri variants resolve ok)
darobin: who wants plural?
[ 6 ]
darobin: who wants singular?
[ 3 ]
<darobin> PROPOSED RESOLUTION: template URI assignment for intents is http://intents.w3.org/*
<richt> my vote was, either works for me but the ambiguity has been lodged in my mind when I write a web app and need to recall it in the future from memory :)
<fjh> proposed RESOLUTION: template URI assignment for intents is http://intents.w3.org/* where * is action or type
RESOLUTION: template URI assignment for intents is http://intents.w3.org/*
<darobin> as noted above, intents.w3.org should be as strict in its resolution of stuff as possible
[ Lunch for 1 hour ]
<richt> lunch with an s or not.
fjh: we're thinking about going
to the border Cafe
... how many people are interested?
[ 15 hands ]
fjh: let's say 6pm
Zakimm, aaaa is gmandyam
s/Zakimm, aaaa is gmandyam//
<Paul_Kinlan> Paul Kinlan on gvoice
jhawkins: mounir / sicking aren't
... we wrote up an analysis of their api
... they're closer to our api than we thought
jhawkins: the namespace on
actions is different
... they use just the name "pick", "share", "edit"
... whereas we use intent.w3.org/pick ...
scribe: they're using an
... so you can't have the intent payload available onload
... we've reached an agreement that there should be an Intent event
... for delayed delivered
fjh: i don't think that has been incorporated in the spec yet
jhawkins: that's an action we need to have/do
<fjh> ACTION: jhwawkins to add event for on load to webintents spec [recorded in http://www.w3.org/2012/07/10-dap-minutes.html#action04]
<trackbot> Sorry, couldn't find user - jhwawkins
s/ACTION: jhwawkins to add event for on load to webintents spec//
s/Sorry, couldn't find user - jhwawkins//
<fjh> ACTION: jhawkins to add event for on load to webintents spec [recorded in http://www.w3.org/2012/07/10-dap-minutes.html#action05]
<trackbot> Sorry, couldn't find user - jhawkins
<fjh> ACTION: jhawkins to add event for on load to webintents spec [recorded in http://www.w3.org/2012/07/10-dap-minutes.html#action06]
<trackbot> Sorry, couldn't find user - jhawkins
scribe: activities uses a DOM Request
<fjh> ok need to do this offline
<jhawkins> "A DOMRequest object represents an ongoing operation; it provides callbacks that are called when the operation completes…"
<jhawkins> it is essentially a Future
<trackbot> ACTION-550 -- James Hawkins to add event for on load to webintents spec -- due 2012-07-17 -- OPEN
jhawkins: Intents have a way for
pages to declaratively register for the Intent without
requiring a manifest
... Activities don't
... There is a way to programmatically register, but that's a different area...
... For imperative registration, Activities has registerActivityHandler
... Intents currently doesn't have registration
richt: I could dynamically add an intent tag to the page, right?
... do i need something in the spec to handle dynamic insertion of <intent> tags?
... you definitely need to check for that, because it's often the case that it doesn't naturally happen
richt: if i change the properties of an <intent> tag, via JS, what's the intended result?
darobin: it might be that
<intent> should handle this the same way <script>
... insertion is honored, but mutation/removal is effectively ignored
<trackbot> ACTION-551 -- James Hawkins to share proposal on list to handle dynamic insertion/removal etc of <intent> tags -- due 2012-07-17 -- OPEN
darobin: wrt. side-effects
<darobin> ACTION: Robin to send some spec text for the way that extras work [recorded in http://www.w3.org/2012/07/10-dap-minutes.html#action07]
<trackbot> Created ACTION-552 - Send some spec text for the way that extras work [on Robin Berjon - due 2012-07-17].
jhawkins: for delivery,
Activities has setMessageHandler
... and Intents has window.intent (and the Intent Event)
<fjh> ACTION: James Hawkins to see this action [recorded in http://www.w3.org/2012/07/10-dap-minutes.html#action08]
<trackbot> Sorry, amibiguous username (more than one match) - James
<trackbot> Try using a different identifier, such as family name or username (eg. jhawkins2, jsalsman)
jhawkins: disposition is the same
... and return mechanism is the same
... activities has postError, intents has postFailure
... but that's the only difference
... those are the differences/similarities we've identified
... even though we've raised a lot of differences, they're all small
richt: when WebActivities made it
to the whatwg list
... they raised UCs that you guys weren't raising
... what happened there?
... why are they saying different UCs?
jhawkins: i know we talked about
... we didn't write about it in our analysis
... that reminds me of another hing
... their list of activities seemed to be fixed
... i'm not sure if that's still the case
fjh: why was their so much wind on the list?
darobin: i think it boils down
about a few things
... one is a lot of people talked about things they /could/ do with Intents
<richt> s/why was their so much/why was there so much/
<Cathy> s/was their so/was there so/
darobin: and mozilla thought they
were core to the spec
... but that comes from not reading the spec
jhawkins: it turns out their spec doesn't have a fixed limit of actions
Paul_Kinlan: their spec encourages URLs for non default types
richt: we shouldn't encourage it, but we should allow it
<fjh> jhawkins: reason for URL is so that documentation can be found at URL - expectation and practice
jhawkins: we think that the
documentation is more important than the namespacing
... there are questions we should post to them
... it's unclear if setMessageHandler supports multiple activities
... it's unclear if a user can pick a particular service
... is there a notion of a picker ui?
... there were two statements saying "web activities isn't a discovery api" "web activities isn't a communications api"
darobin: it isn't, but nor is Web Intents
Paul_Kinlan: i believe this was
from the stale webintents.org/discover
... because that was documented there
jhawkins: sounds good
darobin: sounds good
fjh: is that stale document still around?
... i can delete it
Josh_Soref: please make it 410
Paul_Kinlan: i can't do that, but i will delete it in a few minutes
jhawkins: what can we do to go forward without ruffling feathers?
fjh: didn't greg incorporate some
feedback using language from web activities?
... send a message on web intents suggesting we're done
Josh_Soref: can we have
Paul_Kinlan send a message about having deleted the misleading
... check with greg to see if we incorporated something from activities
jhawkins: Activities start with
creating a DOMRequest
... which is roughly a Promise
darobin: it depends on whether you have 2 callbacks
<fjh> callbacks versus objects with event handlers
darobin: or are going to start
having progress and things
... in which case you want to be able to hang things off of
richt: web activities could
benefit from a lot of the things we've discussed about web
... and it should benefit from within the web intents framework
... we should have one of the mozilla guys coming onboard as an editor
fjh: let's start with an email
jhawkins: i'll write one
... one of our issues with Web Activities is that the api relies on 2 apis not in the system
... System Message Handler and DOMRequest
jhawkins: we should move to bugzilla
fjh: can we dispense with those issues?
<fjh> inline disposition needed and if so is SSL required for it
<fjh> rational is need for uniform security of all parts of client page, e.g. if client page protected by SSL then also inlined content...
Josh_Soref: this came up @CoreMob two weeks ago
jhawkins: i'm not opposed to this
<fjh> ACTION: fjh to summarize issue and rationale regarding SSL for inlined webintents content [recorded in http://www.w3.org/2012/07/10-dap-minutes.html#action09]
<trackbot> Created ACTION-553 - Summarize issue and rationale regarding SSL for inlined webintents content [on Frederick Hirsch - due 2012-07-17].
<Paul_Kinlan> webintents.org/discover now 410 Gone's and reference is removed from webintents.org/
jhawkins: but it'd be helpful if someone came up with an example
<fjh> jhawkins: how is it different if it is in a new tab
<fjh> jhawkins: have todo item for showing status for items including inline
<fjh> josh_soref: once there is a security loss one cannot get back
<fjh> fjh: need the concept of a "secure page"
<fjh> richt: http and https would be treated as different origins
<fjh> richt: same origin policy
<fjh> jhawkins: need to gather info so we can make an informed decsiont
<fjh> issue event on Intent load (performance issue related to blocking)
<richt> fyi, postMessage spec says "if the targetOrigin argument is an absolute URL, and the Document of the Window object on which the method was invoked does not have the same origin as targetOrigin, then abort these steps silently" http://www.w3.org/TR/webmessaging/#dom-window-postmessage
<richt> (before passing the message to the target origin)
<fjh> I have updated the DAP WebIntents issue wiki to point to Bugzilla, http://www.w3.org/2009/dap/wiki/WebIntent_Issues
<richt> so we should adopt a similar approach with Web Intents.
<Paul_Kinlan> can we post the contact intent demo to IRC?
<richt> s/so we should adopt a similar approach with Web Intents./so we should adopt a similar approach with Web Intents wrt http/https message passing only/
[ Josh_Soref demos installing intent ]
[ Josh_Soref demos breaking Chrome by closing the provider without confirming/canceling ]
jhawkins: perhaps we should post an error code
[ currently it posts an error of <null> ]
richt: i like it
... we don't usually target non browser vendors
Josh_Soref: here browsers will probably implement contacts for devices, but they'll be in the minority
<richt> so the target is primarily web developers directly. I expect most developers don't understand and shouldn't need to learn WebIDL so a different form of documentation might ultimately be more helpful.
<richt> ...for the Contacts Intent
Josh_Soref: tantek sent feedback on contacts a while ago complaining about lack of alignment to vCard 4
fjh: can we agree to publish an
updated draft once darobin finishes editing his draft
... i think we should publish an updated WD
RESOLUTION: Publish Pick-Contacts-Intent as WD with same shortname ("contacts-api")
<jhawkins> Josh_Soref: I need to get rid of one of those accounts. it confuses me as well
<fjh> jungkee gives demo of Pick Media
<fjh> ScribeNick: fjh
richt: what about local intent, is this an issue
<Josh_Soref> s/Josh_Soref: I need to get rid of one of those accounts. it confuses me as well//
<Josh_Soref> richt: how are you handling files?
<Josh_Soref> Jungkee: i'm using URLs, either real or data:
<Josh_Soref> darobin: the problem w/ URLs/Blobs is that the server will have to download the data for 200 videos
<Josh_Soref> ... it'd be useful to have blobs that are lazy pointers to urls
<Josh_Soref> Jungkee: so when the blob tries to trigger the blob, it then triggers the xhr?
<Josh_Soref> darobin: right
<darobin> ACTION: Robin to make a proposal for LazyBlob [recorded in http://www.w3.org/2012/07/10-dap-minutes.html#action10]
<trackbot> Created ACTION-554 - Make a proposal for LazyBlob [on Robin Berjon - due 2012-07-17].
<Josh_Soref> Jungkee: i know that there's a search api that this WG has considered
<Josh_Soref> ... i propose string list searching
<darobin> s/string list/simple string based/
<Josh_Soref> ... also, for metadata, having to define them ...
<darobin> s/has considered/has considered for contacts/
<Josh_Soref> ... i picked Media metadata based on flickr/etc. as well as Media Annotations
<Josh_Soref> Wonsuk: we looked at EXIF/MPEG-7
<Josh_Soref> richt: we should start with a smaller list
<Josh_Soref> Jungkee: the core set from Media Annotation is 27 properties
<Josh_Soref> ... i'd like to drop some of them
<Josh_Soref> Paul_Kinlan: one of the thing the Chrome Apps team as part of Sys Apps Work
<Josh_Soref> ... is to take a File reference via Web Intents
<Josh_Soref> ... so you can get access to raw file itself
<Josh_Soref> ... instead of having to pass around Blobs
<Josh_Soref> ... it's special cased
<Josh_Soref> ... one you get a special cased URL, you can use XHR
<Josh_Soref> ... but you get cross origin issues
<Zakim> fjh, you wanted to discuss roadbump and robin issue, break time
<Josh_Soref> ... lazy blob sounds cool
<Josh_Soref> fjh: sounds like the speed bump discussion is somewhat similar
<Josh_Soref> darobin: it isn't quite the same
<Josh_Soref> fjh: it sounds similar
<Josh_Soref> [ Break ]
<Josh_Soref> fjh: we should publish a new draft
<Josh_Soref> RESOLUTION: We will publish a WD of the Pick-Media Intent with the same short name as Gallery ("Gallery")
<Josh_Soref> jhawkins: how did Gallery appear in the Charter?
<Josh_Soref> Josh_Soref: Gallery/Contacts were initially requested
<Josh_Soref> ... based on the assumption that devices had valuable local stores
fjh: we assume that webintents can be used for both remote and local services
<Josh_Soref> ... but some of us looked at the world and decided that web stores were more likely to be of value
<Josh_Soref> ... so we wanted apis that could handle both
<Josh_Soref> richt: e.g. Unified Addressbook
<Josh_Soref> ... not specifying the source of contacts, but combining local/remote data
<Josh_Soref> Josh_Soref: and thus they were added to the DAP charter ages ago
<Josh_Soref> ... and are relevant with/without Intents
<Josh_Soref> ... Intents is just the way we decided would be best to address them
list of DAP deliverables in charter -> http://www.w3.org/2011/07/DeviceAPICharter#deliverables
<Josh_Soref> s/Apps/Apps and NFC/
<Josh_Soref> jhawkins: what is the relationship between DAP and Sys Apps?
<Josh_Soref> s/Topic: Sys/Topic: History for Sys/
<vandebo> darobin: no
<vandebo> I can be if that would be more useful
<darobin> it depends how much you want to talk :)
<vandebo> The main gallery author (sorry, forget his name) has been focusing the Gallery proposal on the online case, and has suggested deferring the local media case to the sys apps group. This seems counter to the groups intent
<darobin> vandebo, that's not an entirely correct characterisation
<Josh_Soref> fjh: that's not true
<darobin> vandebo, DAP's Gallery is both for local and online, but it is limited in a number of things (e.g. write-back)
<Josh_Soref> ... sys apps is focusing on local cases requiring local permissions and more underlying apis to the platform
<darobin> vandebo, whereas what's in SysApps is far more advanced and complex, and has security implications beyond what is usually acceptable in a browser
<darobin> vandebo, the same applies to contacts and a few other things
<Josh_Soref> richt: sys apps is "throwing the kitchen sink at things"
<Josh_Soref> ... "let's give away the farm"
<Josh_Soref> darobin: that's a decision for Sys Apps to make (after it forms )
<Josh_Soref> fjh: we're defining a light-weight api for accessing things
<vandebo> darobin: ok. I was under the the impression that what I said was accurate from the various list dicussions, but I'll admit that it's not entirely clear. It seems that's not the intention, so my question is moot.
<Josh_Soref> dsr: this group is focusing on cases where the application you visit aren't trusted up front
<Josh_Soref> richt: i know this is sys apps, and sys apps doesn't exist yet
<Josh_Soref> ... but if they want what they make to be available in browsers
<Josh_Soref> ... they'll have to tread carefully
s/we're defining a light-weight api for accessing things/the focus on DAP is for simple applications that can use remote or local resources, so these re relevant to DAP. Sysapps will have more detail for trusted environments and may do similar work, but this should not preclude DAP from doing its work/
discussion of what SysApps should do should not be the discussion of the DAP WG.
<Josh_Soref> dsr: we have two charters
<Josh_Soref> ... for sys apps, we did a poll to find out what people are willing to implement
<Josh_Soref> ... what they're willing to edit
<Josh_Soref> ... what they're willing to write test cases for
<Josh_Soref> ... the charter is split into two phases
<Josh_Soref> ... the first phase is primarily working on Security Model and some test apis
<Josh_Soref> ... that aren't controversial
<Josh_Soref> ... and then there was a problem that the list of apis was too long for a group to work on in its allocated time
<Josh_Soref> ... if the group is successful, it could then take in more items (rechartering)
<Josh_Soref> ... i'm now waiting for W3C Management (W3M) to approve the charter to enter W3 Review
<richt> ScribeNick: richt
<dsr> SysApps: http://www.w3.org/2012/05/sysapps-wg-charter.html
fjh: So we have a charter and chairs listed.
<vandebo> that's me, sorry I don't know the protocol
dsr: next step is for the charter
to be approved.
... the mission statement for sys apps has been 'wobbly'.
... is going to get darobin or fjh to help with that.
fjh: send it over to us and we'll take a look at it
s/over to us and we'll take/over to darobin and I and we'll take/
dsr: hope to get AC approval to start Sys Apps starting next week.
jhawkins: so what is the overlap between DAP and Sys Apps?
darobin: the primary overlap is
around data formats.
... Presumably Sys Apps will have a 'deeper' API that a similar DAP API but presumably it will use the same format.
s/'deeper' API that/'deeper' API than/
jhawkins: It sounds like who you're targetting for implementation is the difference
fjh: we don't need to deep dive
now. The Sys Apps working group will need to tackle these
issues early on.
... In theory the DAP API should be used wherever possible...depending on the requirements,
darobin: there is likely to be
enough of an overlap in membership so that coordination between
Sys Apps and DAP will not be a problem.
... a lot of the people in this room are likely to also be involved in Sys Apps.
... would be useful if, at the beginning of Sys Apps, someone retrace the history of DAP so they don't make the same mistakes.
dsr: At a similar point to Sys
Apps. Still looking for the chairs for that group.
... believe we can go to AC review without having chairs in place.
Proposed NFC charter: http://www.w3.org/2012/05/nfc-wg-charter.html
<gmandyam> Should I just post my question on IRC, or should I ask Dave directly?
gmandyam: Would like a little more detail on Phase 1/2 in Sys Apps.
<fjh> group discussed potential collaboration/overlap with Sys Apps
<fjh> Heads up on progression of charters and AC review plans for these potential WGs
gmandyam: PhoneGap specifically refer to existing APIs. Are you planning to follow that so there's no unnecessary replication of APIs?
dsr: can't speak for the group
directly since it hasn't formed yet.
... the general feeling at the moment though seems to be where APIs are 'good enough' already they will be used.
gmandyam: what is difficult at this point is that multiple APIs already exist and it's going to be difficult to work around that.
dsr: those discussion are still to take place since the group hasn't been formed yet.
gmandyam: ok, thanks.
darobin: several things we can talk about here.
darobin: specifically want to
bring up two things.
... 1. The tutorial for using testharness.js (link provided above by darobin)
... we are getting a lot of input tests that are using the framework slightly wrong
... so hopefully this will help people.
2. W3C Test Framework
s/2. W3C Test Framework/...2. W3C Test Framework/
scribe: lists all the test suites
that the tool knows about.
... allows you to import a test suite from a manifest file (manifests can be generated from a small tool).
... anyone on the web can then run a test suite directly from this framework.
... makes it possible for the web site to gather test results in a distributed way from users.
... so the idea is to group everything, gather lots of data and analyse subtle differences in implementations.
scribe: Test Framework API also
available (link on line above by darobin)
... so you can hook in to the tool from your own code/systems
<Zakim> fjh, you wanted to ask if test app suite requires writing spec in particular manner
fjh: is this stuff seperate from the work that Dom and Marcos did on how to markup tests.
Marcos and Doms test methodology spec: http://www.w3.org/TR/test-methodology/
darobin: what we don't have yet
is consensus on a single way to markup a spec with test
... there are two testing groups in W3C
darobin: I encourage you to join both of these groups
<fjh> this wg is creating driver for automating browser testing, screen testing etc
<fjh> s/this wg/rberjon: this wg/
<fjh> interest group looking at overall W3C testing infrastructure, including test framework etc
<fjh> s/interest group/rberjon: interest group/
s/rberjon: this wg/darobin: this wg
s/rberjon: this wg/darobin: this wg/
dsr: when do these groups expire?
darobin: end of 2013.
... for Web Testing Interest Group.
<Zakim> dsr, you wanted to note that there seems to be some bugs in how results are reported on some platforms
dsr: Playing around with
Vibration test suite yesterday. A couple of minor things came
... the way it reports the platform is a bit strange.
darobin: it gets it from the platform so nothing we can do.
dsr: I was expecting the device
to vibrate on some tests.
... it didn't.
darobin: that seems like it might be a failure.
dsr: it was marked as passed.
darobin: will look in to it.
<Zakim> fjh, you wanted to ask where to look for status of battery, vibration testing
dsr: We're publishing test results without the UA vendors permission. Any problems with that?
darobin: we don't have any problem with that.
fjh: this is all generated from public information
Josh_Soref: IE in pre-release
says that you are not authorized to post write-ups or reports
on those products.
... that's not really a bad thing for a company providing a beta product.
... they have occasionally gone after people for going against these T&Cs.
darobin: Future W3C Test Framework feature: If you have data you don't want to include then you don't include it
fjh: Anonymizing/aggregrating the data is a way to avoid these issues.
<Zakim> fjh, you wanted to mention existing practice
darobin: in practice this shouldn't be an issue since we don't generally have access to internal builds.
Josh_Soref: Where do bug reports go for the W3C Test Framework?
here's a short link to the W3C Test Framework Bugzilla URL: http://bit.ly/Mg3nbX
darobin: Any more q's on testing/interop?
jhawkins: still need help with testing for web intents
fjh: maybe we can talk about that tomorrow.
[fjh goes through the proposed agenda for tomorrow]
fjh: Not sure how much we'll have
on Thursday but we'll have to see.
... tomorrow's agenda is: UPnP/Discovery, Web Intents, [lunch], ...Web Intents, Network Information API.
... Plan to start at 9:30 tomorrow morning.
s/Web Intents, [lunch]/Web Intents (testing), [lunch]/
fjh: Any concerns about the agenda tomorrow?
<fjh> Other topics to follow will be media capture review, network information, sensors
Will be doing a UPnP demo during the UPnP session.
s/Will be doing a UPnP demo during the UPnP session./fjh: Will be doing a UPnP demo during the UPnP session./
fjh: We have a dinner at 6pm
... at Border Cafe, Middlesex Tpk.
... meeting is in recess.
trackbot, end meeting
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Jerome: Jerome Giraud/jgiraud: Jerome Giraud/ Succeeded: s/Lazlo/Laszlo/ Succeeded: s/Tibet/Tibbet/ Succeeded: s/Hersh/Hirsch/ Succeeded: s/Hirsch/Hirsch, Nokia, co-chairing this WG, interested in everything in this group/ Succeeded: s/...Web Intents/...interested in Web Intents/ Succeeded: s/Ken Saku/Kensaku Komatsu/ Succeeded: s/Zakim: thanks.// Succeeded: s/a12u/aizu/ Succeeded: s/Giri Mandyam/Giri Mandyam, Qualcomm/ FAILED: s/... main interest in Web Intents./shan: Soonbo Han, LG Electronics, main interest is Web Intents/ Succeeded: s/Paul_Kinlan:// Succeeded: s/nb/n/ Succeeded: s/inents/intents/ Succeeded: s/../.../ Succeeded: s/one issue is accountability through transparency/one solution is accountability through transparency/ Succeeded: s/scemantic/semantic/ Succeeded: s/linds/lines/ Succeeded: s/nn/n/ FAILED: s/we can make things.*// FAILED: s|s/we can make things.*//|| FAILED: s|josh_soref: we can make things fail more and better|| FAILED: s/WI:/wi:/ FAILED: s/URLS/URLs/ FAILED: s/objct/object/ Succeeded: s/intents is/intents-actions is/ FAILED: s/Zakimm, aaaa is gmandyam// FAILED: s/Tibbet/Tibbett/ FAILED: s/Tibbettt/Tibbett/ FAILED: s/intent.w3/intents.w3/ FAILED: s/..../.../ FAILED: s/delivered/delivery/ FAILED: s/action: jhwawkins to add event for on load to webintents spec// FAILED: s/Sorry, couldn't find user - jhwawkins// Succeeded: s/have/have imperative/ Succeeded: s/hing/thing/ FAILED: s/why was their so much/why was there so much/ FAILED: s/was their so/was there so/ FAILED: s/decsiont/decision/ WARNING: Bad s/// command: s/so we should adopt a similar approach with Web Intents./so we should adopt a similar approach with Web Intents wrt http/https message passing only/ FAILED: s/Josh_Soref: I need to get rid of one of those accounts. it confuses me as well// FAILED: s/string list/simple string based/ FAILED: s/has considered/has considered for contacts/ FAILED: s/Apps/Apps and NFC/ FAILED: s/Topic: Sys/Topic: History for Sys/ Succeeded: s/q// FAILED: s/we're defining a light-weight api for accessing things/the focus on DAP is for simple applications that can use remote or local resources, so these re relevant to DAP. Sysapps will have more detail for trusted environments and may do similar work, but this should not preclude DAP from doing its work/ FAILED: s/over to us and we'll take/over to darobin and I and we'll take/ FAILED: s/'deeper' API that/'deeper' API than/ FAILED: s/targetting/targeting/ FAILED: s/2. W3C Test Framework/...2. W3C Test Framework/ FAILED: s/this wg/rberjon: this wg/ FAILED: s/interest group/rberjon: interest group/ FAILED: s/rberjon: this wg/darobin: this wg/ FAILED: s/rberjon: this wg/darobin: this wg/ WARNING: Bad s||| command: s|https://www.w3.org/Bugs/Public/enter_bug.cgi?assigned_to=mike%40w3.org&blocked=&bug_file_loc=http%3A%2F%2F&bug_severity=normal&bug_status=NEW&comment=&component=Test%20Framework&contenttypeentry=&contenttypemethod=autodetect&contenttypeselection=text%2Fplain&data=&dependson=&description=&form_name=enter_bug&keywords=&maketemplate=Remember%20values%20as%20bookmarkable%20template&op_sys=All&priori FAILED: s|=P2&product=Testing&qa_contact=dave.null%40w3.org&rep_platform=PC&short_desc=&target_milestone=---&version=unspecified|| FAILED: s/Web Intents, [lunch]/Web Intents (testing), [lunch]/ FAILED: s/Will be doing a UPnP demo during the UPnP session./fjh: Will be doing a UPnP demo during the UPnP session./ Found Scribe: Josh_Soref Inferring ScribeNick: Josh_Soref Found ScribeNick: richt Found ScribeNick: richt Found ScribeNick: Josh_Soref Found ScribeNick: fjh Found ScribeNick: richt ScribeNicks: Josh_Soref, richt, fjh Default Present: +1.858.651.aaaa, +46.1.07.15.aabb, nwidell, +358.718.00aacc, Paul_Kinlan, dsr, fjh, Josh_Soref, darobin, shan, lgombos, Milan, richt, kensaku, Cathy, jgiraud, aizu, dcheng3, youenn, jhawkins, gmandyam, Jungkee, +1.510.393.aadd, vandebo Present: +1.858.651.aaaa +46.1.07.15.aabb nwidell +358.718.00aacc Paul_Kinlan dsr fjh Josh_Soref darobin shan lgombos Milan richt kensaku Cathy jgiraud aizu dcheng3 youenn jhawkins gmandyam Jungkee +1.510.393.aadd vandebo Robin_Berjon Frederick_Hirsch jerome_giraud Wonsuk_Lee Dave_Raggett Jungkee_Song Niklas_Widell Rich_Tibbett Agenda: http://www.w3.org/2009/dap/wiki/F2F_Agenda_10-12_July_2012_Burlington_MA_USA Found Date: 10 Jul 2012 Guessing minutes URL: http://www.w3.org/2012/07/10-dap-minutes.html WARNING: No person found for ACTION item: http://www.w3.org/ns/intent#edit [recorded in http://www.w3.org/2012/07/10-dap-minutes.html#action03] People with action items: dsr fjh hawkins james jhawkins jhwawkins rberjon robin[End of scribe.perl diagnostic output]