[![W3C][1]][2]

# Device APIs Working Group Teleconference

## 10 Jul 2012

[Agenda][3]

See also: [IRC log][4]

## Attendees

Present

    Cathy_Chan, Dave_Raggett, Diana_Cheng, Frederick_Hirsch, Giri_Mandyam,
Hiroyuki_Aizu, James_Hawkins, Jean_Michel_Rouger, Josh_Soref, Jun_Fujisawa,
Jungkee_Song, Kensaku_Komatsu, Laszlo_Gombos, Milan_Patel, Naoyuki_Sato,
Niklas_Widell, Paul_Kinlan, Richard_Tibbet, Robin_Berjon, Soonbo_Han,
Steve_VanDeBogart_(vandebo), Wonsuk_Lee, Youenn_Fablet, jerome_giraud

Regrets


Chair

    Robin_Berjon, Frederick_Hirsch

Scribe

    Josh_Soref

## Contents

  * [Topics][5]

    1. [Welcome][6]

    2. [Phone Introductions][7]

    3. [Agenda review][8]

    4. [Minutes Approval][9]

    5. [HTML Media Capture][10]

    6. [Battery][11]

    7. [Vibration][12]

    8. [Proximity][13]

    9. [WebIntents][14]

    10. [Agenda Additions][15]

    11. [WebIntents Namespacing][16]

    12. [Dinner Tonight][17]

    13. [Web Activities API][18]

    14. [Webintents Issues wiki][19]

    15. [darobin's Contacts Intent][20]

    16. [History][21]

    17. [History for Sys Apps and NFC][22]

    18. [NFC][23]

    19. [Interop and Testing][24]

  * [Summary of Action Items][25]

* * *

<trackbot> Date: 10 July 2012

<fjh> Meeting: Device APIs Working Group Face-Face 10-12 July 2012, Burlington
MA

<scribe> Scribe: Josh_Soref

### Welcome

fjh: restrooms are outside

... There's a cafeteria down the hall

... We should use it

jhawkins: James Hawkins

... At Google

... I'm interested in WebIntents

dsr: Dave Raggett

... W3C

... I'm measured on recommendations per minute

jgiraud: Jerome Giraud

... Orange

... Global interest apis

Milan: Milan Patel

... Huawei

... Standards, W3C is in my area

... Within DAP, WebIntents are my main interest

Cathy: Cathy Chan, Nokia

Lgombos: Laszlo Gombos

... Nokia

richt: Richard Tibbett

... Opera

... I lead extensions and device apis

... Interested in WebIntents

... And sensors

<Paul_Kinlan> Paul_Kinlan is joining now, just need to find a room

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

... co-chairing with Frederick and interested in everything.

youenn: Youenn Fablet, Canon, interested in Web Intents and media capture API

kensaku: Kensaku Komatsu

... interested in Web Intents

naoyuki: Naoyuki Sato, Sony

... interested in combination of web with home networks

aizu: Hiroyuki Aizu

... interest is in Web Intents / integration of home network / cloud services.

... 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.

jun: Jun Fujisawa, Canon

dcheng3: Diana Cheng, Vodafone

... interested in Web Intents, Network Information API, Sensors.

shan: Soonbo Han, LG Electronics, main interest is 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.

... Working on Tizen as well. Working on Gallery API based on Web Intents.
Interested in additional Web Intents-based APIs.

Jungkee: Jungkee Song

### Phone Introductions

nwidell: Niklas Widell

... interest in Web Intents, Sensor APIs and Capture parts.

Paul_Kinlan: Paul Kinlan, Google.

... primarily interested in Web Intents.

gmandyam: Giri Mandyam, Qualcomm

Introductions done.

<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."

### Agenda review

[fjh runs through the proposed meeting agenda]

fjh: Any suggestions on the agenda just ping me offline.

Agenda approved.

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][26]]

<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].

### Minutes Approval

<fjh> Approve minutes from 27 June

<fjh> [http://lists.w3.org/Archives/Public/public-device-
apis/2012Jun/att-0104/minutes-2012-06-27.html][27]

<fjh> proposed RESOLUTION: Minutes from 27 June 2012 are approved

**RESOLUTION: Minutes from 27 June 2012 are approved**

### HTML Media Capture

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][28]

<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 quite complete

... 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

... like

... 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 LC

... 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.**

### Battery

<darobin> [http://dev.w3.org/2009/dap/camera/?specStatus=LC;publishDate=2012-0
7-12;lcEnd=2012-08-09;previousPublishDate=2012-05-29;previousMaturity=WD][29]

<fjh> Battery in CR [http://dvcs.w3.org/hg/dap/raw-
file/tip/battery/CR.html][30] ;

<fjh> open actions to produce test cases; ACTION-522, ACTION-523 able to exit
CR after 1 July.

fjh: Battery is in CR

<fjh> ACTION-522?

<trackbot> ACTION-522 -- Robin Berjon to write tests for Battery -- due
2012-03-28 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/522][31]

<fjh> ACTION=523?

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

### Vibration

<fjh> Vibration in CR [http://www.w3.org/TR/2012/CR-vibration-20120508/][32] ;

<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

### Proximity

<fjh> Proximity - latest editors draft , [http://dvcs.w3.org/hg/dap/raw-
file/tip/proximity/Overview.html][33]

fjh: Paul_Kinlan

... 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

fjh: I'll send dougt an email

... 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 draft

... 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][34]]

<trackbot> Created ACTION-549 - Prepare CfC to publish FPWD of Proximity API
[on Robin Berjon - due 2012-07-17].

### WebIntents

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 about FPWD

... 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

... (disposition)

... 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

<darobin>
[https://developers.google.com/events/io/sessions/gooio2012/216/][35]

jhawkins: we need to find a way for people to be hands on

... writing demo code

... to tease out some of these bugs

... Related...

... mounir posted the WebActivities counter-proposal

... we could go over them today?

... I think there are some Issues?

fjh: we could go over Explicit Intents

... i think it's sparse in the spec

jhawkins: that's a good point

... 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 it

... 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 disposition

... 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 explicit intent

... 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 an application

... 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

Josh_Soref: could change explicit intent mechanism to open connection, load
page, but not share data initially

jhawkins: this is a possibility

... 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 API

... 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 interaction?

... 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 issue

... 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 weeks ago

... 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 things

... 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 intents

... 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 nice

... i don't think it works right now

<Zakim> Josh_Soref, you wanted to say this sounds like a need for persisted
connections to intents

Paul_Kinlan: i think we need delayed delivery

Josh_Soref: agree with frederick, if client makes request to use intent, user
agent can persist future requests without repeated picker

... this could apply to speed bump case as well

... also gallery

... 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 in well

... 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

... have mail web client which has address book with explclit intent to use
that address book

... but I want to use anther book, so first see nothing much, then want to get
to other book

... so even with same origin want to go to different address book

... 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> a/anther/another/

u-turn is going back from explicit choice to pick after all

Josh_Soref: pleased that people are realizing my previous ideas were good

Paul_Kinlan: for explicit intents

... 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 bit awkward

... 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 browser-user-preference

... 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 shift-click out

... 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

... share/edit/upload

... 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

### Agenda Additions

jhawkins: webintents issues wiki

... w3.org namespacing for intents

... web activities

### WebIntents Namespacing

jhawkins: the proposal is to move the namespace to W3.org

<jhawkins> W3.org proposal for namespacing:

<jhawkins> for **ACTION:** [http://www.w3.org/ns/intent#edit][36]

<jhawkins> for type: [http://www.w3.org/ns/intent#image][37]

dsr: there was a proposal on W3 Team

... 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

... 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> [http://www.w3.org/ns/intent#edit][36]

<darobin> [http://www.w3.org/ns/intent#pick][38]

<darobin> [http://www.w3.org/ns/intent#image][37]

<darobin> [http://www.w3.org/ns/intent#contact][39]

<darobin> @prefix wi: <[http://www.w3.org/ns/intent#>][40]

<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 everything 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 type

... 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 was saying

... schema.org didn't exist

... when we looked at webintents.org

... we could have subtypes / arbitrary strings

... we have microformats

... there are activity streams

... i don't know that we need to manage it on w3c

jhawkins: for apis we're creating/standardizing

... 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> [http://w3.org/intent/share][41]

[http://intent.w3.org/share][42]

jhawkins: that works for me too

dsr: there may be some pushback

<jhawkins> [http://intents.w3.org/share][43] -- perhaps

darobin: one of the things that came up

... 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 push it

... the ecosystem is small enough to be able to do it

richt: i know this was feedback on WhatWG

... 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][44]" and in my web app I
use "[http://www.w3.org/ns/intent#image][37]" from memory. What happens here?

richt: we've seen this problem w/ XML NS

jhawkins: intents.w3.org

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 the past

... what about a trailing / ?

darobin: when you get it wrong, nothing happens, you immediately know your
code is broken

Josh_Soref: we should make failures clear and obvious

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

... 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 object

... which maps back to the string

jhawkins: sounds like we're solving the wrong problem

... it sounds like a lot of hand-waiving

richt: you could have a [http://intent.w3.org:80/share][45]

... it resolves, people may expect it works

... or [http://intent.w3.org/share/][46]

... you'll end up w/ half of the developers writing one way

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> So I will potentially have 3 services for
[http://intent.w3.org:80/share][45], 4 services for
[http://intent.w3.org/share][42], 8 services for
[http://intent.w3.org/share/][46]

<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/*][47]

<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/*][47] where * is action or type

**RESOLUTION: template URI assignment for intents-actions is
[http://intents.w3.org/*][47]**

<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.

### Dinner Tonight

fjh: we're thinking about going to the border Cafe

... how many people are interested?

[ 15 hands ]

fjh: let's say 6pm

### Web Activities API

<Paul_Kinlan> Paul Kinlan on gvoice

jhawkins: mounir / sicking aren't here

... we wrote up an analysis of their api

... they're closer to our api than we thought

<jhawkins> [https://wiki.mozilla.org/WebAPI/WebActivities][48]

jhawkins: the namespace on actions is different

... they use just the name "pick", "share", "edit"

... whereas we use intents.w3.org/pick ...

... they're using an event

... so you can't have the intent payload available onload

... we've reached an agreement that there should be an Intent event

... for delayed delivery

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:** jhawkins to add event for on load to webintents spec
[recorded in [http://www.w3.org/2012/07/10-dap-minutes.html#action03][49]]

<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#action04][50]]

<trackbot> Sorry, couldn't find user - jhawkins

jhawkins: activities uses a DOM Request

<fjh> ok need to do this offline

<nwidell> [https://developer.mozilla.org/en/DOM/DOMRequest][51]

<jhawkins> "A DOMRequest object represents an ongoing operation; it provides
callbacks that are called when the operation completes…"

<jhawkins> it is essentially a Future

<fjh> ACTION-550?

<trackbot> ACTION-550 -- James Hawkins to add event for on load to webintents
spec -- due 2012-07-17 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/550][52]

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 imperative registration

richt: I could dynamically add an intent tag to the page, right?

jhawkins: yes

... do i need something in the spec to handle dynamic insertion of <intent>
tags?

Josh_Soref: yes

... 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>
does

... insertion is honored, but mutation/removal is effectively ignored

<fjh> ACTION-551?

<trackbot> ACTION-551 -- James Hawkins to share proposal on list to handle
dynamic insertion/removal etc of <intent> tags -- due 2012-07-17 -- OPEN

<trackbot> [http://www.w3.org/2009/dap/track/actions/551][53]

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#action05][54]]

<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#action06][55]]

<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 for both

... 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 that

... we didn't write about it in our analysis

... that reminds me of another thing

... their list of activities seemed to be fixed

... i'm not sure if that's still the case

fjh: why was there 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

<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

jhawkins: reason for URL is so that documentation can be found at URL -
expectation and practice

... we think that the documentation is more important than the namespacing
itself

... 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?

Paul_Kinlan: yes

... 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 webintents.org/discover

... 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

<darobin> [http://scriptlib-cg.github.com/api-design-cookbook/#specifying-
callbacks][56]

richt: web activities could benefit from a lot of the things we've discussed
about web intents

... 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

### Webintents Issues wiki

jhawkins: we should move to bugzilla

<jhawkins> fjh:
[https://www.w3.org/Bugs/Public/enter_bug.cgi?product=Web%20Intents][57]

fjh: can we dispense with those issues?

<fjh> [http://www.w3.org/2009/dap/wiki/WebIntent_Issues][58]

<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#action07][59]]

<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

... how is it different if it is in a new tab

... have todo item for showing status for items including inline

Josh_Soref: once there is a security loss one cannot get back

fjh: need the concept of a "secure page"

richt: http and https would be treated as different origins

... same origin policy

jhawkins: need to gather info so we can make an informed decision

... 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][60]

<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][58]

<richt> so we should adopt a similar approach with Web Intents wrt http/https
message passing only

<Paul_Kinlan> can we post the contact intent demo to IRC?

<fjh> [Contacts-Intent Service (demo)][61]

### darobin's Contacts Intent

[ 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")**

<fjh> jungkee gives demo of Pick Media

<fjh> draft -> [https://dvcs.w3.org/hg/dap/raw-
file/29d23bcac5ee/gallery/Overview.html][62]

richt: what about local intent, is this an issue

... how are you handling files?

Jungkee: i'm using URLs, either real or data:

darobin: the problem w/ URLs/Blobs is that the server will have to download
the data for 200 videos

... it'd be useful to have blobs that are lazy pointers to urls

<fjh> lazy blob

Jungkee: so when the blob tries to trigger the blob, it then triggers the xhr?

darobin: right

<darobin> **ACTION:** Robin to make a proposal for LazyBlob [recorded in
[http://www.w3.org/2012/07/10-dap-minutes.html#action08][63]]

<trackbot> Created ACTION-554 - Make a proposal for LazyBlob [on Robin Berjon
- due 2012-07-17].

Jungkee: i know that there's a search api that this WG has considered for
contacts

... i propose simple string based searching

... also, for metadata, having to define them ...

... i picked Media metadata based on flickr/etc. as well as Media Annotations

Wonsuk: we looked at EXIF/MPEG-7

richt: we should start with a smaller list

Jungkee: the core set from Media Annotation is 27 properties

... i'd like to drop some of them

Paul_Kinlan: one of the thing the Chrome Apps team as part of Sys Apps Work

... is to take a File reference via Web Intents

... so you can get access to raw file itself

... instead of having to pass around Blobs

... it's special cased

... one you get a special cased URL, you can use XHR

... but you get cross origin issues

<Zakim> fjh, you wanted to discuss roadbump and robin issue, break time

Paul_Kinlan: lazy blob sounds cool

fjh: sounds like the speed bump discussion is somewhat similar

darobin: it isn't quite the same

fjh: it sounds similar

[ Break ]

fjh: we should publish a new draft

**RESOLUTION: We will publish a WD of the Pick-Media Intent with the same
short name as Gallery ("Gallery")**

### History

jhawkins: how did Gallery appear in the Charter?

Josh_Soref: Gallery/Contacts were initially requested

... based on the assumption that devices had valuable local stores

fjh: we assume that webintents can be used for both remote and local services

... but some of us looked at the world and decided that web stores were more
likely to be of value

... so we wanted apis that could handle both

richt: e.g. Unified Addressbook

... not specifying the source of contacts, but combining local/remote data

Josh_Soref: and thus they were added to the DAP charter ages ago

... and are relevant with/without Intents

... Intents is just the way we decided would be best to address them

<fjh> list of DAP deliverables in charter ->
[http://www.w3.org/2011/07/DeviceAPICharter#deliverables][64]

### History for Sys Apps and NFC

<darobin> [Proposed SysApps WG Charter][65]

jhawkins: what is the relationship between DAP and Sys Apps?

<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

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)

fjh: 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

richt: sys apps is "throwing the kitchen sink at things"

... "let's give away the farm"

darobin: that's a decision for Sys Apps to make (after it forms )

fjh: 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

<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.

dsr: this group is focusing on cases where the application you visit aren't
trusted up front

richt: i know this is sys apps, and sys apps doesn't exist yet

... but if they want what they make to be available in browsers

... they'll have to tread carefully

<fjh> discussion of what SysApps should do should not be the discussion of the
DAP WG.

dsr: we have two charters

... for sys apps, we did a poll to find out what people are willing to
implement

... what they're willing to edit

... what they're willing to write test cases for

... the charter is split into two phases

... the first phase is primarily working on Security Model and some test apis

... that aren't controversial

... and then there was a problem that the list of apis was too long for a
group to work on in its allocated time

... if the group is successful, it could then take in more items
(rechartering)

... i'm now waiting for W3C Management (W3M) to approve the charter to enter
W3 Review

<dsr> [Proposed SysApps WG Charter][65]

<dsr> [Proposed NFC WG Charter][66]

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 darobin and I and we'll take a look at it

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 than a similar DAP API but
presumably it will use the same format.

jhawkins: It sounds like who you're targeting for implementation is the
difference

fjh: correct

... 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.

### NFC

<richt> [Proposed NFC WG Charter][66]

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.

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.

### Interop and Testing

darobin: several things we can talk about here.

<darobin> [using-testharness.js][67]

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.

<darobin> [W3C Test Framework][68]

darobin: 2. W3C Test Framework

... 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.

<darobin> [JSON for Element Traversal test cases][69]

<darobin> [Test Framework JSON API][70]

darobin: 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.

<richt> [Marcos and Dom's test methodology spec][71]

darobin: what we don't have yet is consensus on a single way to markup a spec
with test assertions.

... there are two testing groups in W3C

<darobin> [W3C Web Testing Activity][72]

darobin: I encourage you to join both of these groups

<darobin> [WebDriver API specification][73]

<fjh> darobin: this wg is creating driver for automating browser testing,
screen testing etc

<fjh> rberjon: interest group looking at overall W3C testing infrastructure,
including test framework etc

<darobin> [Web Testing Interest Group][74]

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 up.

... 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?

<darobin> [Report a bug against W3C Test Framework in Bugzilla][75]

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 (testing), [lunch],
...Web Intents, Network Information API.

... Plan to start at 9:30 tomorrow morning.

... Any concerns about the agenda tomorrow?

<fjh> Other topics to follow will be media capture review, network
information, sensors

fjh: Will be doing a UPnP demo during the UPnP session.

... We have a dinner at 6pm tonight.

... at Border Cafe, Middlesex Tpk.

... meeting is in recess.

trackbot, end meeting

## Summary of Action Items

**[NEW]** **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][26]]

**[NEW]** **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#action07][59]]

**[NEW]** **ACTION:** James Hawkins to see this action [recorded in
[http://www.w3.org/2012/07/10-dap-minutes.html#action06][55]]

**[NEW]** **ACTION:** jhawkins to add event for on load to webintents spec
[recorded in [http://www.w3.org/2012/07/10-dap-minutes.html#action03][49]]

**[NEW]** **ACTION:** jhawkins to add event for on load to webintents spec
[recorded in [http://www.w3.org/2012/07/10-dap-minutes.html#action04][50]]

**[NEW]** **ACTION:** rberjon to prepare CfC to publish FPWD of Proximity API
[recorded in [http://www.w3.org/2012/07/10-dap-minutes.html#action02][34]]

**[NEW]** **ACTION:** Robin to make a proposal for LazyBlob [recorded in
[http://www.w3.org/2012/07/10-dap-minutes.html#action08][63]]

**[NEW]** **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#action05][54]]


[End of minutes]

* * *

Minutes formatted by David Booth's [scribe.perl][76] version 1.135 ([CVS
log][77])

$Date: 2009-03-02 03:52:20 $

   [1]: http://www.w3.org/Icons/w3c_home

   [2]: http://www.w3.org/

   [3]:
http://www.w3.org/2009/dap/wiki/F2F_Agenda_10-12_July_2012_Burlington_MA_USA

   [4]: http://www.w3.org/2012/07/10-dap-irc

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #item05

   [11]: #item06

   [12]: #item07

   [13]: #item08

   [14]: #item09

   [15]: #item10

   [16]: #item11

   [17]: #item12

   [18]: #item13

   [19]: #item14

   [20]: #item15

   [21]: #item16

   [22]: #item17

   [23]: #item18

   [24]: #item19

   [25]: #ActionSummary

   [26]: http://www.w3.org/2012/07/10-dap-minutes.html#action01

   [27]: http://lists.w3.org/Archives/Public/public-device-
apis/2012Jun/att-0104/minutes-2012-06-27.html

   [28]: http://lists.w3.org/Archives/Public/public-device-
apis/2012Jul/0005.html

   [29]: http://dev.w3.org/2009/dap/camera/?specStatus=LC;publishDate=2012-07-
12;lcEnd=2012-08-09;previousPublishDate=2012-05-29;previousMaturity=WD

   [30]: http://dvcs.w3.org/hg/dap/raw-file/tip/battery/CR.html

   [31]: http://www.w3.org/2009/dap/track/actions/522

   [32]: http://www.w3.org/TR/2012/CR-vibration-20120508/

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

   [34]: http://www.w3.org/2012/07/10-dap-minutes.html#action02

   [35]: https://developers.google.com/events/io/sessions/gooio2012/216/

   [36]: http://www.w3.org/ns/intent#edit

   [37]: http://www.w3.org/ns/intent#image

   [38]: http://www.w3.org/ns/intent#pick

   [39]: http://www.w3.org/ns/intent#contact

   [40]: http://www.w3.org/ns/intent#>

   [41]: http://w3.org/intent/share

   [42]: http://intent.w3.org/share

   [43]: http://intents.w3.org/share

   [44]: http://w3.org/ns/intent#image

   [45]: http://intent.w3.org:80/share

   [46]: http://intent.w3.org/share/

   [47]: http://intents.w3.org/*

   [48]: https://wiki.mozilla.org/WebAPI/WebActivities

   [49]: http://www.w3.org/2012/07/10-dap-minutes.html#action03

   [50]: http://www.w3.org/2012/07/10-dap-minutes.html#action04

   [51]: https://developer.mozilla.org/en/DOM/DOMRequest

   [52]: http://www.w3.org/2009/dap/track/actions/550

   [53]: http://www.w3.org/2009/dap/track/actions/551

   [54]: http://www.w3.org/2012/07/10-dap-minutes.html#action05

   [55]: http://www.w3.org/2012/07/10-dap-minutes.html#action06

   [56]: http://scriptlib-cg.github.com/api-design-cookbook/#specifying-
callbacks

   [57]: https://www.w3.org/Bugs/Public/enter_bug.cgi?product=Web%20Intents

   [58]: http://www.w3.org/2009/dap/wiki/WebIntent_Issues

   [59]: http://www.w3.org/2012/07/10-dap-minutes.html#action07

   [60]: http://www.w3.org/TR/webmessaging/#dom-window-postmessage

   [61]: http://berjon.com/contacts-intent/service

   [62]: https://dvcs.w3.org/hg/dap/raw-
file/29d23bcac5ee/gallery/Overview.html

   [63]: http://www.w3.org/2012/07/10-dap-minutes.html#action08

   [64]: http://www.w3.org/2011/07/DeviceAPICharter#deliverables

   [65]: http://www.w3.org/2012/05/sysapps-wg-charter.html

   [66]: http://www.w3.org/2012/05/nfc-wg-charter.html

   [67]: http://darobin.github.com/test-harness-tutorial/docs/using-
testharness.html

   [68]: http://w3c-test.org/framework/app/suite

   [69]: http://w3c-test.org/framework/api/test-cases/elementtraversal

   [70]: http://w3c-test.org/framework/docs/api/

   [71]: http://www.w3.org/TR/test-methodology/

   [72]: http://www.w3.org/testing/

   [73]: http://dvcs.w3.org/hg/webdriver/raw-file/default/webdriver-spec.html

   [74]: http://www.w3.org/testing/ig/

   [75]: https://www.w3.org/Bugs/Public/enter_bug.cgi?component=Test%20Framewo
rk&product=Testing

   [76]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

   [77]: http://dev.w3.org/cvsweb/2002/scribe/