Draft Minutes: 30 October 2012

The Draft minutes from WebApps' October 30 f2f meeting are in 
<http://www.w3.org/2012/10/30-webapps-minutes.html> and are copied below.

If you have any corrections, please send them to this list by November 6.

-Thanks, AB

W3C <http://www.w3.org/>


  - DRAFT -


  WebApps F2F Meeting


    30 Oct 2012

Agenda <http://www.w3.org/wiki/Webapps/TPAC2012Meeting>

See also:IRC log <http://www.w3.org/2012/10/30-webapps-irc>


    Attendees

Present
    Art_Barstow, Adrian_Bateman, Tobie_Langel, Arnaud_Braud,
    Olli_Pettay, Mike_Smith, Bryan_Sullivan, Hao_Dong, Magnus_Olsson,
    Wayne_Carr, Jonas_Sicking, Simon_Pieters, James_Graham,
    Lachlan_Hunt, sgodard, Hiroyuki_Aizu, Brady_Eidson,
    Maciej_Stachowiak, Wonsuk_Lee, Norbert_Lindenberg, Adam_Klein,
    Soonbo_Han, Travis_Leithead, Ryan_Sleevi, Kenji_Baheux,
    Julian_Aubourg, Eduardo_Fullea, Jungkee_Song, Odin_Horthe_Omdal,
    Sakari_Poussa, Mounir_Lamouri, Greg_Billock, Alexandre_Morgaut,
    Kris_Krueger, Hallvord_Steen, Alex_Russell, Robin_Berjon,
    Paul_Bakaus, Tomoyuki_Shimizu
Regrets
Chair
    Art, Charles
Scribe
    Josh_Soref, Josh


    Contents

  * Topics <http://www.w3.org/2012/10/30-webapps-minutes.html#agenda>
     1. Agenda Bashing
        <http://www.w3.org/2012/10/30-webapps-minutes.html#item01>
     2. Testing <http://www.w3.org/2012/10/30-webapps-minutes.html#item02>
     3. Introductions
        <http://www.w3.org/2012/10/30-webapps-minutes.html#item03>
     4. IME <http://www.w3.org/2012/10/30-webapps-minutes.html#item04>
     5. Selectors API Level 2
        <http://www.w3.org/2012/10/30-webapps-minutes.html#item05>
     6. AppCache, Offline, Packaged WebApps, App Manifest, ...
        <http://www.w3.org/2012/10/30-webapps-minutes.html#item06>
     7. Web Platform Docs
        <http://www.w3.org/2012/10/30-webapps-minutes.html#item07>
     8. Testing (James Graham)
        <http://www.w3.org/2012/10/30-webapps-minutes.html#item08>
     9. Testing the Web Backwards, Lyon
        <http://www.w3.org/2012/10/30-webapps-minutes.html#item09>
    10. XMLHttpRequest
        <http://www.w3.org/2012/10/30-webapps-minutes.html#item10>
    11. Web Driver
        <http://www.w3.org/2012/10/30-webapps-minutes.html#item11>
    12. Testing Tutorial by James and Simon
        <http://www.w3.org/2012/10/30-webapps-minutes.html#item12>
    13. Web Intents
        <http://www.w3.org/2012/10/30-webapps-minutes.html#item13>
  * Summary of Action Items
    <http://www.w3.org/2012/10/30-webapps-minutes.html#ActionSummary>

------------------------------------------------------------------------

<ArtB> ScribeNick: ArtB

<scribe> Scribe: Josh_Soref

Date: 30 October 2012

<Lachy> scribenick: Lachy

<ArtB> ScribeNick: Lachy

chaals:we'll begin, first, figure out what's left on the agenda

… Process stuff to continue with


      Agenda Bashing

… real discussions: Offline app cache, widget packaging, proposals, etc.

… IME, Selectors API 2. Short, do together in a session

… Testing.

… We have a session on web intents at 16:45

IDL2. Do people want to get into technial discussion?

… Maybe/

… It's possible that next year's TPAC will be in Asia.

We are proposing to have an F2F in Silicon Valley for HTML and WebApps

We did it in May this year. Think it was worth doing

… Anyone object?

… Assuming people want to turn up. The current idea is the week of April 
22. HTML gets a couple of days, webapps gets a couple of days.

… Who would be likely to turn up in CA in April? [Dozen or so hands raised]

…One of the things worth thinking about is that we have virtually no 
joint meetings at this F2F. TPAC is where we can invite other groups to 
talk to us.

… We should think about the groups who we should be talking to.

… Templates. Are we going to make any progress today? Worth continuing?

… No. Drop it off the agenda.

… Paul suggested yesterday that a zip archive API would be useful. There 
have been proposals before.

… It's probably not in our current charter.

… The rule is that we have to change the charter to work on new work. 
Complicated process.

… Do we think it's worth doing?

sicking:We just shipped an API for this.

… We think it would be useful.

<bryan> +1 to considering zip archive API

<sgodard> +1 for ZIP archive API

tobie:When we talked about App cache in London, there was a lot of use 
cases that could be fulfilled by the archive API.

Chaals:does anyone object?

maciej:Can someone give a brief pitch about why it's useful for the 
platform?

<adrianba> s/XXX/tobie/

<ArtB> Mozilla bughttps://bugzilla.mozilla.org/show_bug.cgi?id=772434

sicking:The requests have come from the gaming community. They make a 
single request to download resources for a game. Want to be able to 
extract specific files as needed from the package.

… Reduce number of requests, getting compression from zip.

maciej:has anyone done any testing to see if zip performance is better 
than other approaches?

sicking:no.

<bryan> the use cases I am thinking of are similar, e.g. generically the 
ability to download content as a package and store locally for use in 
the app

… I don't think it's just performance. Convenient for deployment to have 
a single file.

chaals:Chair hat off. One of our metrics is developer convenience

… People are used to working with zip archives, have tools for it.

… Could argue that HTTP pipelining is an alternative approach, but 
working with zip is something people are used to doing and won't be 
difficult.

sicking:We did do an API and got feedback saying it wasn't the right 
approach. There are many ways to do it, difficult to get right.

maciej:For the use cases, it seems useful to download a zip and then 
reference its resources by URL.

sicking. It would be useful to have a zip protocol handler.

… It could possibly work with a URL, like jar handler.

maciej:Is there a list of these use cases?

sicking:I can get them.

chaals:We need to go through formal call for concensus.

… The decisions in this meeting aren't binding; call for concensus on 
mailing list.

… The next step will be to send a proposal to the list, make a formal 
work item, have call for concensus on the list.

… We can get into the technical details then.

<scribe>*ACTION:*Chaals: Get the ZIP archive proposal on the table as a 
formal work item. [recorded 
inhttp://www.w3.org/2012/10/30-webapps-minutes.html#action01]

<trackbot> Created ACTION-673 - Get the ZIP archive proposal on the 
table as a formal work item. [on Charles McCathie Nevile - due 2012-11-06].

maciej:I want to the use cases on the table.

chaals:We will. That comes with the proposal. Discussion about it will 
take place over several weeks.

… Testing. We had this as an agenda topic.

… We could spend a lot of time looking in details, or we could spend the 
extra time actually making tests.


      Testing

Chaals:We need a test facilitator.

… It's useful to have a person overseeing the creation of the testsuite. 
Not necessarily writes all the tests themselves.

… I have a list of specs that currently don't have a test facilitator.

… I'm going to read them out, ask for volunteers.

Art:People can think about it and get back to chaals or I.

Chaals:The list of things we want is someone to co-ordinate things for 
DOM Parsing and Serialisation

… All of the file specs.

… XHR

… Full screen API

… Gamepad

… Templates

… Progress events

… This is a pretty small thing, but kind of annoying because you need 
another spec to test them in.

… Push API.

… Pointer API

… Server sent events.

… Screen orientation

… Streams

… App Manifest

jgraham, The point of the test facilitator is not that you have to write 
the tests. You take responsibility for making sure there is a test suite.

julian:I volunteer for XHR

sgodard:I volunteer for App Manifest

chaals:I have a proposal for something that falls into the App Cache 
area. Not sure if this is the right group. Called Prefetch.

… It allows a site that uses a lot of resources again and again, give a 
manifest of files to prefetch.

… Not sure if I'm going to propose it as a work item.


      Introductions

Norbert Lindenberg working on ECMAScript Internationalization API under 
contract for Mozilla.

[inaudible]

XXX, Telefonica, used to be AC Rep. Push API

<ArtB> s/XXX, YYY/Norbert Linbenberg/


      IME

Kenji Baheux I would like to talk about IME API.

… Today I would like to show use cases, explain what IME is.

… It would help if I could present something on the screen.

Chaals:We had a discussion about IME. Someone started making a sales 
pitch about why it's a great thing. Don't give us the sales pitch, give 
us the usecases.

Kenji Baheux: Starting with the use cases

… The first one is on search websites, there are suggestions for what 
the user is currently typing.

… Bad overlap from the IME suggestions and the search suggestions.

… A lot of complaints from Chinese and Japanese users.

… Suggestions shown based on Kanji.

… Overlapping suggesitons shown on screen.

… Try to find a better way to combine search suggestions and IME 
suggestions.

… Second category. Games.

… Two use cases. 1. On Windows, if you play a FPS game, and you press 
one of the IME keys, it creates problems. Need to avoid IME menu 
interferring with game.

… 2. Entering a name in a game, native UI for IME suggestion doesn't fit 
with game design UI.

… Third; Presentation software. Editing text in fields using IME 
interfers with live preview.

… Sample API shown on screen.

chaals:There is a discussion in HTML about Input Mode.

… When you have an input for text or phone numbers, right now, it's kind 
of painful. Being able to give a hint about expected input is useful.

… e.g. If I have my keyboard set to Russion, username in russion, 
password in english. Is that usecase related?

Kenji Baheux: Somewhat related.

chaals:What's the implementation status?

Kenji Baheux: No implementation.

Chaals:Would anyone like to work on it?

adrianba, I recognise the use cases. I wasn't completely clear on the 
scope of the proposal. Can you clarify for me which use cases are 
solving with the current spec?

KenjiBX:Currently in scope: Composition stream.

… Also get the different boundaries.

… Can also render your own composition text.

<odinho_>The @inputmode attribute in HTML 
<http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#input-modalities:-the-inputmode-attribute>

… You can let the browser know what's happening so it can avoid the 
system IME or adapt the site design and behaviour to the IME.

… Custom IME design for games case not covered by the spec.

… Presentation case is covered.

adrianba, You mentioned the JavaScript API for disabling the IME. For a 
long time in IE, we've had IME mode CSS mechanism for disabling IME.

<chaals> [Sorry Dmitry, but it was when you started getting impassioned 
that it started turning into a sales pitch… I thought you had explained 
your technical perspective well enough to let people think about the 
ideas...]

… It's in one of the draft specs. Have you considered that and is it 
similar?

KenjiBX, There is a function for that to hit at that. Similar to CSS, 
but in JS.

adrianba, maybe we could consider if we need both.

adrianba:Microsoft is interested in improving this general area, but 
highest priority is the the use case around positioning.

… Seems like it's not currently covered by the spec.

… If we add that, it would be substantial scope change.

… that's the place where we'd most like to work on this. What are your 
priorities?

KenjiBX:I'm interested in that. Thought about it.

mounir:First use case is like a UA implementation details.

… The UA could just show it correctly and not have the two UIs.

… I was wondering for the styling use case. Have you considered CSS?

KenjiBX:Yes.

[could not hear answer properly]

mounir:Why don't you think it's a UA implementation detail?

KenjiBX:I think it's better to let the web app decide on the best UX for 
this case.

maciej:I think there might be a misunderstanding. The candidate window 
is provided by the OS, the suggestions are provided by the web app.

… Need to tell the IME system where to put the IME popup.

… I agree with Microsoft about what the most important use cases are. 
Avoiding candidate window and overlap.

… The other cases seem periferal.

… It seems to be designed solely for the purpose of implementing their 
own input methods. I don't think that is a good idea. JS implementations 
are not likely to work across devices.

<MikeSmith> pbakaus, we're talking about IME here in webapps

KenjiBX:The current draft says the UA can get the current position of 
the candidate window. [???]

chaals:chair hat off: In many ways I agree that JS is a terrible way to 
handle user input in general. Handling keyboard input breaks 
accessibility, etc.

… Except that we use it because the Operating Systems don't make things 
easy.

… In Yandex Translate, we provide an input method for converging latin 
characters into Russian, or vice versa.

… So I'm nervous about focussing on the use case of a site being able to 
build its own IME.

… The overlapping of the suggestion and IME is a bigger problem.

… Agree with mjs.

… A lot of assisted input systems fake being a keybaord. Concerned about 
the interaction with this API.

… Authors make assumptions about the user's keyboard that are not true.

… This is an area where I would expect comments about robustness.

… This is a warning of things I've seen go wrong

mjs:For touch screen devices that have touch screen keyboards, if you've 
written a custom IME that works for keyboards, it's most likely going to 
break on the iPad virtual keyboard.

… I think using JS for this is intrinsicly not cross platform.

chaals:True, but my TV doesn't have a russion keyboard option.

Alex:I think it's interesting that there is a battle for control between 
the OS and JavaScript.

chaals:More technical comments?
... Break. No coffee for 30 minutes. 15 minute break. Then short session 
on selectors API 2.

<jcdufourd_> nick jcdufourd


      Selectors API Level 2

<mjs> ScribeNick: mjs

LH:I'll start by giving an overview
... functionality of the find and matches methods is pretty stable
... test suite has many tests
... hopefully we can get implementations soon
... I'm hoping we can settle the naming issue for the methods find and 
findAll
... Issue for parsing comments in selectors still needs to be addressed 
- hopefully CSS WG can address it in Selectors 4
... there was a brief discussion with Anne about merging Selectors API 
v2 with DOM4
... and possibly introducing extra functionality
... I wanted to discuss the return type for the findAll method
... NodeList, Array, or some new object that provides a combination of 
functionality
... Use cases:
... (1) get a collection of elements as a result of the query
... (2) run methods that apply collectively to all the elements
... right now you have to iterate individually
... (3) filter the list or run additional queries on the list
... (4) do method chaining, just like in jQuery
... possible solutions:
... (a) normal JavaScript array - would give normal Array functionality 
but could not add selectors-specific methods (e.g. having a new 
.findAll() make a union)
... (b) return a NodeList; but no Array-like functionality
... (c ) define a custom object which imports functionality from Array 
and NodeList, but adding Selectors-specific stuff

AR:I'm from ECMA TC39; hard to add Array functionality due to NodeList 
because of closures
... I'd prefer to define an Array subtype or to recast NodeList as an Array
... there's a preference to make these things Arrays from the pov of 
developers and JavaScript

CMN:I'd like to address names
... everyone likes find(), findAll(), right?

(no objections heard)

CMN:that's straw consensus and it's a non-technical issue

LH:that about covers it

CMN:as an implementation question, what about compatibility?

LH:the problem with converting NodeList to an Array is that NodeLists 
are generally live in many uses so you can't import mutable methods from 
Array

AR:I actually don't think that's a big problem
... Mozilla, first, the liveness is a feature of someone else holding an API
... this is not something that is foreign
... but for the question of adding new invariants, we can model that 
with proxies

CMN:any other comments, questions?

LH:matches() is implemented with a prefix in all browsers
... no one implements scope or reference nodes yet

CMN:any other implementor notes?

TL:just an observation that the extra functionality for chaining seems 
like a much more generic feature - maybe should not be specific to 
Selectors API, maybe should be in DOM 4

CMN:back to agenda
... working backwards, at 16:45 we have Web Intents - can't change that 
time, dial-in
... session on testing, James has agreed to lead
... the goal is to sit in the room and write tests - hands-on session
... will end at 16:45 and will begin when we finish everything else
... after lunch, short session on the Web Platform effort
... those guys do documentation, that's useful
... closer to the concerns of this group, a session on web driver
... test harness for browsers to avoid manual tests
... at 11:15 (which means 11:30) we are going to have a session on 
appcache, offline cache, manifest formats, etc
... at 10:30, coffee break
... it's 10:30 now, coffee break

<krisk> jgraham - let me know when you pushed the opera websocket tests 
and I'll help convert so of them

<ArtB> ScribeNick: ArtB


      AppCache, Offline, Packaged WebApps, App Manifest, ...

CMN:we have a couple of specs in our charter

… e.g. Widgets

… and application manifest

<timeless> scribe: Josh

<timeless> scribenick: timeless

chaals:in html, there's AppCache
... loved by everybody
... because it allows you to do the same thing
... with wonderful functionality
... so wonderful that darobin will describe it
... mozilla has a json based manifest
... i tossed into an email the prefetch stuff we're looking at

<ArtB> ED for App manifest 
is:http://dvcs.w3.org/hg/app-manifest/raw-file/tip/index.html

chaals:i don't know if this group is interested in this stuff
... we are
... because it gives big improvement in load times
... this is a free form discussion
... where are we at
... what are the pieces of this stuff and who are using it
... people are building widget systems
... can we unify it
... should it be our problem, html's problem, someone else's problem
... a lot of the people who can give input are in this room-group
... i'd like to start this discussion with what is html's appcache doing

darobin:AppCache - a small group of people have been meeting in corners 
to take it to the WG
... something will start happening "very soon"
... as soon as html enters CR
... so in a few weeks
... i'd be happy for someone else to take it

sicking:mozilla organized one of these dark corners
... we're very interested in making appcache work

<bryan> is there a doc ready to be shared from the dark corners, soon?

sicking:from our point of view -- it doesn't
... from our point of view, how much back compat we keep is up for 
discussion
... we haven't had anyone to put together a proposal
... and we haven't found a good venue
... i'm reluctant to have someone submit a proposal to the HTML ML
... i'd prefer to have a separate ML
... a separate ML is required

<Zakim> chaals, you wanted to try and squash the naming issue

sicking:i'd prefer to do it somewhere else
... either in this WG
... i believe it's still in our charter
... we can transfer from HTML to this WG
... or do it in a CG

<Zakim> mjs, you wanted to talk about venue

mjs:w/ my HTML WG cochair hat
... i don't have a strong opinion about this WG or that WG
... there's definitely precedence for WebApps taking up when it's more 
non-markup level
... there's also precedence for adding apis on, such as data-cache api
... i don't think HTML WG would object
... i think HTML WG would support extensions to HTML
... w/ my vendor hat on, i'm ok w/ either group
... i'm also happy to see the proposal in super sketchy form
... i've heard of the proposal
... but without details to know if we, Yandex, would be interested

darobin:i had 2 questions for sicking / anyone else
... you mentioned potential backwards compat breaking changes
... i'm not sure it's a good/bad idea
... i'm wondering how serious you are about that

sicking:we don't have a proposal
... we haven't figured out a cohesive idea

<adrianba> here are some of the ideas 
->http://lists.w3.org/Archives/Public/public-html/2012Sep/0060.html

sicking:the most tangible thing i can say is
... we want to get rid of this whole master entry idea
... add more JS API to it
... so you can add/remove to-from the AppCache
... and create an appcache for an origin
... re:back-compat because we don't have anything more tangible, it can 
go either way
... i think we can do most things w/o breaking
... but if getting rid of master entries breaks it, then...

darobin:re:venue
... i can understand why you'd be reluctant to work w/ html
... we're trying to make this WG a friendly venue
... the way it's broken now is shameful
... if whomever @mozilla would like to sit down with me,

<tobie>https://etherpad.mozilla.org/appcache-london,https://etherpad.mozilla.org/appcache

darobin:i'm happy to share it with the group

tobie:there's output from both meetings which i shared

slightlyoff:we're interested in all of this
... we have similar thinking
... about optionality of master
... we want to make camping of a domain more controllable

pbakaus:we have such a mess right now
... i think it's important to have a workshop w/ industry leaders
... i count us as one of them, we really want this

<Zakim> mjs, you wanted to talk about compatibility

mjs:i'd like to make a plea for compat
... it doesn't have to be fully back-compat w/ syntax and features
... maybe there's versioning
... we do have content that uses the current format
... it's more common on mobile
... mobile apps seem to tend to try half backed tech
... i see the great importance of providing a better model
... it's clear from web-dev feedback that current app cache doesn't meet 
their needs and isn't a good design
... i'm interested in seeing ideas which improve it
... even breaking the model

adrianba:agree w/ mjs
... and about compat
... it's inevitable that we'll have to make breaking changes
... we're keen on making sure that existing content keeps working
... ms is interested in working on this as well
... i pasted the link ms sent to html-wg a little while ago
... in IE10, we supported an additional mechanism that extends the manifest
... we provided it in the html5 bug database
... which allows you to change the way the manifest works
... this was essential to making Exchange offline mail work

sicking:not breaking existing content seems like a requirement
... arranging a workshop or something
... i feel like we should get to the point of having concrete proposals 
to discuss
... they always reached a halt when it comes to coming up w/ proposals 
for fixing it
... it takes too much time to come up w/ proposals

chaals:12 months ago, there was a workshop on exactly this topic
... they concluded exactly what we just said

timeless:[Scribe: why did i have to minute this whole thing if that 
workshop did this already?]

chaals:there's position papers...
... i keep on hearing this, yeah we want to do these things
... it seems we're really in a position where writing a proposal is less 
work than spending two days in a workshop
... we could make the workshop unpleasant to encourage writing a proposal
... perhaps the venue question is part of the issue
... talking about it here, it's in scope for this WG
... we really do have on our charter the ability to do this
... you can bring your proposal here
... i'd like to do something
... AppCache is one part of this
... metadata stuff around an app
... widget configuration/packaging
... or mozilla's proposal
... which was just sat on for a few months
... a JSON based more or less equivalent functionality
... is in this WG as a listed item
... i'd like to understand if it's worth working on this stuff
... as a vendor, yandex has stuff which does apps based on a JSON package
... as our app is built from Chromium, it uses the same JSON as Chrome
... which is similar to Mozilla
... there's the dark corner of widget spec backers
... mutterings is
... given there's roundtripping between JSON and XML
... unifying that isn't really difficult
... wondering if people from those corners are interested in that as a 
workitem
... i don't think it's scope creep
... it's a fairly straightforward is a simple conversion of values
... just as mozilla-chrome is straightforward
... Q: what are the workitems we should take up
... do we think doing it here is the right place

<bryan> yes, it should be done, and here

ArtB:art barstow, nokia
... about venue
... i'm mostly indifferent about here, HTMLWG or a CG
... (which was already created)
... but in considering venue, we need producers/consumers of appcache to 
be comfortable to come in and give feedback
... i think a CG may be more comfortable for them
... hashing out multiple drafts there may be easier before a WG

paulc:interested in knowing if anyone is in this WG
... that isn't in HTML WG
... wants to do this work here
... HTML WG is about to be rechartered
... we'd like this to be clarified before we're rechartered
... if you don't clarify today
... before we meet Thu/Fri
... an AC question
... if we proposed Yes/No for doing AppCache in our charter
... will there be objections from Member companies in this room
... that aren't in our group?

sicking:i can't speak officially for mozilla
... i'm not sure we'd object for it to be in charter
... i'd personally prefer WebApps WG or a CG
... i feel so far
... we've had an easier time talking about these things on webapps ML
... i feel like this isn't super tied into HTML as a Markup Language
... scope wise, it makes as much sense here as HTML
... i don't think we'd object to it being in HTML WG

chaals:Yandex, first preference is doing it in Web Apps WG
... second preference is the Native WebApps CG
... which is dormant
... third preference is HTML
... if it doesn't work out like that, we're not going to object
... we have a strong preference, but won't spend our life arguing about it

adrianba:Adrian, Microsoft
... i proposed to continue this discussion in the HTML WG
... because it's already in the spec
... MS has no objection for doing it here
... we had the data-cache discussion
... we prefer one WG or the other
... [i.e. not a CG]

chaals:how many people feel we shouldn't do this work anywhere

mjs:stop trolling the WG

chaals:how many people couldn't care less where the work takes place
... how many people have a preference for where the work takes place?
... i'll pass the mic around, and ask you to state your preference

pbakaus:Zynga, web apps because i believe most of the apis should be in js

hsivonen:XXX, webapps, good track record of WG

adrianba:MS, i gave my preference, but guess it'll be in WebApps

darobin:HTML, because i think we'll fix that group, and it'll rock

[ laughter ]

SimonPieters:Opera, WebApps because it's a functional group and HTML 
currently isn't

sicking:first preference is "Fix AppCache CG"
... second preference is WebApps WG

smaug:WebApps, what hsivonen said

rafaelw:Google, WebApps it makes sense here

chaals:this is the side that doesn't care

odinho_:Opera, WebApps

<bryan> webapps, because we see this as related to app packaging and 
synergistic with the webapps experience with widgets, and other APIs 
that webapps may consider (e.g. offline webapp support in general)

bryan:AT&T, WebApps, we see this related to webapp packaging, 
synergistic w/ widgets
... and offline in general

chaals:ignoring darobin (good idea)
... there's a strong preference here to do it here
... for the people who care
... if we said, hey paulc, we think we'll do it here
... tell HTML WG that WebApps wants to do it here, and themselves
... will we have a turf war?

paulc:i don't know the answer, we'll find out on thursday

chaals:message to HTML WG is "we want it here, if that's ok with you guys"

paulc:chairs should take an action to send a message to the html wg

<npdoty> wasn't mjs's comment earlier that he didn't expect that to be a 
particular problem?

paulc:the question applies to html wg too
... is there anyone in html and not in webapps who'd object to it not 
being in html
... i took the silence as "no one objected to it being in html"

sicking:i'll object to do it in the html wg on the main ML

<ArtB>*ACTION:*barstow respond to HTMLWG's question re WebApps has a 
strong preference to work on AppCache in WebApps WG [recorded 
inhttp://www.w3.org/2012/10/30-webapps-minutes.html#action02]

<trackbot> Created ACTION-674 - Respond to HTMLWG's question re WebApps 
has a strong preference to work on AppCache in WebApps WG [on Arthur 
Barstow - due 2012-11-06].

sicking:but wouldn't object to it being its own ML

<mjs> npdoty, I don't expect it to be a problem but paul is correct that 
there could be people who would have strong feelings about doing it in 
html wg that have not spoken up yet

chaals:we'll send an email to HTML we'd like to do it here
... what are issues other than lack of concrete proposals

<npdoty> mjs, understood, thanks for clarifying

chaals:appcache
... without anyone speaking up, we don't care

pbakaus:for the record, we, Zynga, think it's worth doing

chaals:we could entertain the question
... within JSON based metadata

<bryan> AT&T thinks its worthwhile to evolve and converge the widget 
specs with whatever comes out of the appcache evolution

chaals:we'd like to see JSON convergence

sicking:when we submitted, we didn't hear any response
... so i'm surprised to hear
... and happy to hear, if that's no longer the case

<bryan> the lack of response may be simply a bandwidth issue

sicking:we were planning on submitting it to sysapps
... along with a runtime
... i think runtime+packaging go together
... they're co-dependent
... i'm wondering if group is working on packaging format + runtime
... feedback from google people on mozilla's spec
... was we don't understand the security implications
... it fits strangely in my mind with "but we're shipping an app store 
solution based on it"
... what is it with this
... are you just not interested in convergence

slightlyoff:our format creates a separate origin
... to the extent that they're independent, we don't have the same 
problems we'd have as when we join it with the rest of the web

sicking:google's answer was "it doesn't make sense to define a packaging 
format before you have a runtime"
... the packaging format describes what you put into the runtime
... my question is "should we do that work here"
... otherwise, it's in the sysapps charter
... i'm fine with it in either
... but discussions will happy in sysapps regardless

chaals:i here myself and sicking saying we'd like convergence on JSON

<ArtB> here is a related email from Adam 
Barthhttp://lists.w3.org/Archives/Public/public-webapps/2012AprJun/1017.htmlre 
Manifest and SysApps WG

chaals:pbakaus saying they'd like to see convergence for XML w/ JSON 
(for packaging)
... onus would be on us to produce a convincing proposal

darobin:or just do the work

chaals:right
... so we might end up in sysapps w/ manifest
... which brings us back to appcache

timeless:i will protest if i'm minuting this discussion next year

chaals:appcache
... we note the lack of concrete proposals

pbakaus:an implementation detail
... i'd like to make sure it works w/ file system apis we discussed 
yesterday
... our main goal is to limit the number of requests we make
... it needs to be highly dynamic

[ silence ]

shepazu:is the queue empty because people don't think app cache is needed

sicking:problem is we don't have any proposals to discuss

odinho_:what sicking said [+1]

chaals:my impression too

<slightlyoff> what sicking said

<bryan> we havent seen into the dark corners yet, once there are 
proposals it will be good to consider and discuss them.

<slightlyoff> (I've been working on something for months and it's nearly 
out, but not there yet)

pbakaus:maybe we can get a wishlist about what we want this to cover

<odinho_> bryan: The stuff on the mozilla etherpad exist.

<odinho_> [2]https://etherpad.mozilla.org/appcache

<odinho_> [3]http://www.w3.org/2011/web-apps-ws/

chaals:we could, i've sat through two of those already
... any proposal that would be accepted would have to point to a 
wishlist/requirements reference

<odinho_>Appcache London <https://etherpad.mozilla.org/appcache-london>

<ArtB> ScribeNick: ArtB

<odinho_>AppCache second meeting <https://etherpad.mozilla.org/appcache>

Josh:we need some requirements work first

… before we start on the spec

<timeless> chaals: +1 from a WG member

<odinho_> s,[2]https://etherpad.mozilla.org/appcache,,

<odinho_> s,[3]http://www.w3.org/2011/web-apps-ws/,,

<timeless> s/work first/work - published - first/

<scribe> ScribeNick: timeless

<odinho_> s|s,[3]http://www.w3.org/2011/web-apps-ws/||

<odinho_> s|s,[2]https://etherpad.mozilla.org/appcache,,||

chaals:add an XHR update after lunch
... i won't be here after lunch

ArtB:displaying tentative agenda this afternoon
... come back @1:30pm
... shepazu will talk about web platform docs
... i was hoping Simon Stuart would talk about WebDriver

<odinho_> s|[3]http://www.w3.org/2011/web-apps-ws/||

ArtB:jgraham to talk about testing

s/Stuart/Stewart/

<odinho_> s|[3]http://www.w3.org/2011/web-apps-ws/||

jgraham:i guess, what we do depends on what people are interested in
... good time to gauge that
... how many are interested in hearing about testing at all?

[ nearly half ]

shepazu:who isn't interested in testing?

chaals:if you don't want to talk about testing, you can skip most of the 
afternoon

jgraham:sounds like TestTheWebForward w/ liam
... introduction on how to write tests
... get people writing tests

<odinho_> s|w/ liam|Lyon|

jgraham:maybe an opportunity to have a discussion amongst the people who 
have to run the test

ArtB:thanks jgraham

<odinho_> s|[2]https://etherpad.mozilla.org/appcache||

<ArtB> ScribeNick: ArtB


      Web Platform Docs

Doug's 
presentation:http://www.w3.org/Talks/2012/10-lea-webplatform/wpd-talk/#intro

http://www.webplatform.org/


      Testing (James Graham)

<scribe> ScribeNick: lachy


      Testing the Web Backwards, Lyon

jgraham:I will talk for up to 30 mintues. Then we will get people 
writing tests.
... In the past 12 to 18 months, the testing situation at the W3C has 
improved a lot.

… When CSS 2.1 was going to REC, there was a big panic about there being 
no tests.

… Now we are starting to have some agreement about what format to write 
tests in.

… The same format for WebApps, HTML, etc.

… The tests are all in mercurial repo.

…http://dvcs.w3.org/hg/webapps/

… [Showing the repo website on the screen]

… We have a folder for each spec, containing all of its tests.

… For each, there is an "approved" directory and "submitted" directory.

<ArtB>http://w3c-test.org/webapps/

… This is a bit annoying right now, so we are going to try and develop a 
system much like they have in CSS, where the spec can be annotated with 
relevants tests.

<ArtB> Example of approved 
tests:http://w3c-test.org/webapps/WebSockets/tests/

<ArtB> …http://w3c-test.org/webapps/WebSockets/tests/approved/

jgraham:the situation now is that we are accepting tests in 3 formats, 
depending on what you're trying to test.

… For this group, we want to test DOM APIs, so we can write tests using 
JavaScript.

… testharness.js framework for writing tests.

… Similar in idea to others like QUnit, etc.

<ArtB> …https://github.com/jgraham/testharness.js

… For cases where rendering is important, we use reference tests. You 
two files. One uses the thing being tested. One creates the same 
rendering using different techniques.

… If the two look the same, then you assume it works. If they're 
different, the test fails, something is broken.

… We also have self-describing tests.

… This is basically a list of steps that describe what to do and what 
the result should be.

<ArtB> … testharness tutorial by Robin 
Berjon:http://darobin.github.com/test-harness-tutorial/docs/using-testharness.html

… I will now go through the features of testharness.js. Then in the next 
session, people can try writing some tests.

darobin, I suggest we put that documentation on w3c-test.org

jgraham:[Slides on screen, from testing the web forward event in paris]

… For testing JS, no manual interaction

… Two types of tests.

… 1. Synchronous tests.

… [Showing boilerplate test file on screen]

… The function called test takes another function as a parameter. The 
inner function runs the actual test, with various assertions. e.g. 
assert_true(…)

… [Showed example assertion from a spec]

… [Now showing an example testing function that tests this assertion]

… 2. Async tests.

… Some tests depend on waiting for events, network responses or other 
non-synchronous features.

… Test authors should write using the normal event handlers for the 
feature being tested and include test functions within those event handlers.

… [Example on screen showing an asynchronous test function called by 
setTimeout]

… t.step() takes a function, which runs the tests.

… t.step_func() is similar, but generates a testing function, which may 
be used directly as an event or timeout handler.

… [Showing an example assertion from the local storage spec]

… [Example tests the onstorage event. Uses t.step_func() to generate an 
event handler for onstorage. Includes assertions to verify the result.]

… This includes multiple assertions in the single tests. But if one 
fails, the whole test fails.

… We can set more properties on the test that are useful as metadata.

… The CSS WG used <link rel="help"> to link to the part of the spec 
being tested.

… What we can use instead is a help property to point at the part of the 
spec being tested.

… This helps identify which parts of the spec have and have not been tested.

… PLH has been working on adding this for HTML.

… I propose that we structure the directories based on the section of 
the spec.

Lachy:I don't like the idea of using directory structure as a kind of 
metadata.

jgraham:There are pros and cons. THis is an issue that can be discussed 
tomorrow or some other time.

The step_func() method lets authors specify a timeout for an individual 
test.

s/The step_func()/... The step func()/

… The setup() method allows setting a global timeout for the entire 
testsuite.

s/step func()/async_test()/

… There are a range of asserts. e.g. assert_true, assert_false, etc. 
(Others shown on screen)

… assert_throws knows how to capture an exception and check that it's 
the right one.

… A notification API allows you to findout when certain things occur 
during the test, using callbacks.

… There is lots of documentation.

… darobin has written a tutorial as well.

at 16:00, we will try writing some test.

<darobin>http://darobin.github.com/test-harness-tutorial/docs/using-testharness.html-> 
Test Harness Tutorial

<SimonPieters>http://w3c-test.org/resources/testharness.js


      XMLHttpRequest

<darobin> Julian Aubourg

julian:We have a test coverage report for XHR

… There is a CSS and Javascript file that can generate this report 
within the specs.

jgraham:There will be more sessions on testing tomorrow.


      Web Driver

<odinho_> Simon Stewart

Simon:My name is Simon Stewart

… Over here we have Andreas from Opera, David who works on Firefox and 
Mozilla web driver, XXX who works on Chrome's

… Demo.

… We have support for tests written in python, java c#, etc. Basically 
any language.

… Facebook have contributed PHP bindings.

… There are Perl bindings as well.

… Demo, on screen.

… Obtaining a driver instance using: d = webdriver.Firefox()

… [More code on screen]

… We have a version of Firefox

… Using d.get() method to navigate to URL

… d.find_element() method to find elements in a page by an attribute value.

… e.send_keys() simulates keyboard input

… Demo of WebDriver playing the piano.

… Javascript based piano. WebDriver is sending click events to the piano 
keys on the page.

… Demo was using Chrome.

… We also support Opera

… Using web driver to send keyboard inputs

… Also querying using javascript and JSON to find out the position of 
items on the screen, in order to play a game.

… What are the kinds of thing that people are doing with these things?

… QA engineers doing end-to-end testing of their systems.

… With high fidelity user input, we can do things like drag and drop.

… On Chrome and Opera, those browsers have been modified to allow web 
driver to inject events directly

… For IE and Firefox, we get hold of the hwnd and pump WM messages into it.

… The second audience are browser vendors.

… They want to be able to test their browser before inflicting it upon 
the world.

… The third audience is spec authors wanting to write conformance tests 
for things that can't be expressed solely in javascript.

… Interacting with modal dialogs, for example, or other things that 
require user interaction.

… Web Driver can handle alert(), prompt(), etc.

<Zakim> darobin, you wanted to ask about device interaction

darobin:One of the problems we had trouble automating is platform device 
functions. No way to detect and verify physical actions, like phone 
vibrations.

simon:It's fairly easy to extend.

… We mandate that implementations should communicate in a common way, to 
reduce fragmentation of implementations.

… That's a high level overview. Any questions?

SimonPieters:For the W3C tests, jgraham said we have 3 formats. Can we 
replace manual tests with WebDriver tests?

simon:The manual tests which are a sequence of user interaction and 
checking the result are good candidates for web driver.

… There may be edge cases where we don't have that functionality.

… We have an advanced interaction API.

… We have a basic touch implementation.

Lachy:Is there any ability to interact with the browser chrome.

simon:Not yet. Possible to extend into this area in the future.
... web driver is an attempt to avoid getting into a place where web 
apps cannot be automatically tested.

ArtB:How much time before the web driver spec is at feature freeze?

simon:We're kind of doing this backwards. The implementations are fairly 
solid.

… Lots of major companies. Facebook, Mozilla, BBC, etc. are happy to put 
a lot of weight behind this.

… The actual specification is lagging behind.

… If you were able to look at the open source tree, you would be able to 
make a compatible implementation today.

… We are working on porting our tests to a W3C test suite alongside the 
specification.

ArtB:If you have comments, submit them sooner rather than later.

John:(Microsoft, Principle testee for IE). I was in the meetings for web 
driver spec. We are looking at and and trying to evaluate it. Cannot say 
whether we weil support it.

simon:Mozilla will be using WebDriver extensively

<adrianba> s/testee/test lead/

odinho_:Is it possible to take control over the browser and interact 
with it yourself while web driver script is running.

<JohnJansen> s/John/JohnJansen

<adrianba> s/we weil/we will/

simon:It's a bad idea. Mozilla runs it in a non-interactive way.

<adrianba> s/in the meetings/in the meetings as an observer/

… For people who run websites, it is possible to detect if web driver is 
being used by the client.

… I would be interested in providing a way to identify when a browser is 
under web driver control.

… I will hang around if people want to ask me questions later.

… Thank you

ArtB:Break.

… jgraham will continue with testing at 16:00. Web Intents will start at 
16:45

… testing is at 15:30 instead

<ArtB> ScribeNick: ArtB


      Testing Tutorial by James and Simon

JG:if you have any questions about writing tests, Simon and I would be 
glad to help

… just let us know

<hsivonen> /join #tpac

<hsivonen> doh

<jaubourg> \o/

<sgodard> Great, It's very cool with tests inside document, good job


      Web Intents

<Lachy> Greg: I'm going to talk about web intents and our prototype 
implementation

<Lachy> … Web Intents is a draft in collaboration with device APIs.

<Lachy> … It's kind of like an RPC framework, when one app can start an 
activity that is satisfied by another web app.

<Lachy> … You can see some extensions and apps I have installed in 
Chrome. (on screen)

<tantek> is anyone there from Mozilla to bring up web activities?

<Lachy> … The page has a way to pick an image from anotehr web app. If i 
click on this button, it takes me to another app called Quicksnapr.

<Lachy> … Using web cam APIs to take a picture directly on the web page.

<Lachy> … [taken several pictures]

<Lachy> … Can pick one and send it back to the Imagemator app (the first 
one he started at)

<Lachy> … Using file system API to save the picture locally.

<Lachy> … I can now load up another local Chrome app and see the image 
on the local file system.

<Lachy> … The apps don't necessarily know about each other. The intents 
allow them to be loosely hooked up in an adhoc way.

<tantek> mounir - glad to hear it. carry-on then. thanks.

<Lachy> … The nice thing is that the first web app that launches the 
intent doesn't have to know about the next one.

<Lachy> … That's the loosely couple benefit that comes from this system.

<Lachy> … It does cause some problems though.

<Lachy> … The current status: We've done a tonne of work on the 
mechanics of the spec, resolving ambiguities, standard spec work, etc. 
Also developed an interchange format.

<Lachy> … e.g. the details of how an image gets transferred from point A 
to B

<Lachy> … More to come. e.g. When we first proposed this API, we were 
thinking in terms, than when picking an image, you would always get 
specific user interaction approaches.

<tantek> jgraham - re: <intent> -http://w3cmemes.tumblr.com/post/22399681762

<Lachy> … That was a mistake. We want to move to an event model.

<Lachy> … The problems are mostly around the UI and figuring out the 
responsibilities of the UA and web app.

<Lachy> … The first one is that when you have a few tabs cooperating. I 
have one tab that started the intent, another that satisfied the intent.

<hober> tantek jgraham: alsohttp://w3cmemes.tumblr.com/post/29085196102

<Lachy> … How should this link be conveyed to the user.

<Lachy> … How to manage the fact that there are two tabs involved in the 
same activity.

<Lachy> … We thought the web app picker would be a benefit becuase they 
can select a new app that could satisfy the intent.

<Lachy> … The use of this picker is a lot higher than we would like.

<Lachy> … It ends up being a lot of steps.

<Lachy> … User has to check permissions when setting up a new app. 
Incorporating app discovery and installation into the picker doesn't 
work, from a user interaction perspective.

<Lachy> … If we imagine a defaulting model, where there is a system 
default for known intents.

<Lachy> … So users wouldn't be presented with the picker so often. They 
would just use their default.

<Lachy> … It's possible that these issues may need API tweaks to solve them.

<Lachy> In Chrome 24, the feature is behind an experimental flag.

<Lachy> … that's basically the demo and getting everyone up to speed. 
Any questions or discussion?

<Lachy> Greg. It has changed. For a while we thought we needed extra 
metadata in the pay load.

<Lachy> … Currently the API is very task oriented.

<Lachy> … If the model is more a persistent system or app to app 
connection, that may not be the best API to use.

<Lachy> XXX: You spoke a lot about interacting with 2 tabs. Could you 
explain?

<odinho_> s/XXX/mounir/

<Lachy> Greg: There's 1 tab that initiates the intent, one that 
satisfies it. What should happen if the user closes the second tab. How 
should that be handled by the browser or the web app? These issues are 
not clear.

<Lachy> … I characterise it as more of a UI problem that browser vendors 
need to pay attention to.

<Lachy> sicking: I haven't been following web intents, but I was under 
the impression that there was some mechanism to set up a communication 
link between two tabs. Is that there?

<Lachy> Greg: The way the experiement works in Chrome is that there's 
always a UI that the service presents.

<Lachy> … The tab is always opened either inline or in a new tab.

<Lachy> XXX: Chromes specification indicates that there is a pause 
attribute.

<odinho_> s/pause/ports/

<odinho_> s/XXX/mounir/

<hsivonen> jgraham, consider <intent> objected to

<Lachy> s/pause/port/

<Lachy> Greg: It passes a structured clone.

<shan> s/experiement/experiment/

<Lachy> YYY: I wonder about the servicing page.

<Lachy> Greg: The draft spec calls for ways to register dynamically as a 
extension or app with a manifest

<Lachy> Greg: For Chrome 24, we were experiementing with an icon in the 
URL bar tha when clicked would should things like bookmark, share, etc. 
with some app that you have installed. That would use the intent system 
to link with apps.

<Lachy> s/tha/that/

<Lachy> sicking: The impression I got around intents is that hte hard 
part is building a user experience that basically satisfied the people 
we want to implement the intents. The actual mechanics of shuffling data 
from one tab to another is on the hard bit.

<MagnusOlsson> s/YYY/MagnusOlsson/

<hsivonen> timeless, I object to adding new elements to <head> and I 
object to adding new void elements

<Lachy> Greg: It's like a two sided market. The hope is that there are 
lot of clients and services invoking and servicing intents. Getting that 
market is tough.

<Lachy> … Our initial plan is using features like that dropdown I was 
talking about earlier.

<Lachy> … The reason we don't have that in Chrome 24 is because of the 
UI problems we discoverd.

<Lachy> … Having a bunch of eco systems set up around an API that was 
going to change wouldn't be the best plan. So we hid it behind a flag

<Zakim> npdoty, you wanted to follow up on the distinction between 
user-invoked and page-invoked

<Lachy> npdoty: I mostly work on privacy in standards. To follow up, as 
I understand, the intents spec as it is now, the intents are done as 
service by a user clicking a button.

<Lachy> … But a user could also potentially share any URL from teh 
browser UI, even if the page doesn't explicitly support the intent.

<Lachy> Greg: The spec deals with it in a tangental way. It says that 
the intent may not be invoke by the API given and allows for the browser 
to get in the middle on one end or the other of the system.

<Lachy> … The spec can't force the browser to do it, so it's allowed but 
not mandated in the spec.

<Lachy> … I think we have a good sense of the interchange format to say 
how to transfer images or URLs as a data packet.

<Lachy> sicking: We in Firefox had the need for something similar to 
this, but since web intents wasn't done, we did something else.

<Lachy> … We have web activities which is similar. It has the same 
capabilities. Very much tied into apps. The user brings up an app, 
rather than a new tab.

<Lachy> … one of the UI problems we had is that if you have multiple 
handlers for a given intent, you need to show some sort of UI so the 
user can choose.

<Lachy> … what text string to you put in the title of that UI.

<Lachy> … We put application names next to each option. I don't know if 
you can do that in your implementation, given that there is no trusted 
name for a website.

<Lachy> Greg: In Chrome, the picker has a string that is related to the 
action that was performed by the user. There's a custom string per 
action and a generic one if we don't know what the action is. Something 
like "which service should we use?"

<Lachy> Sicking: how do you describe the options?

<Lachy> Greg: We think that using the name of the app is the most clear. 
The service can provide a custom string for this.

<Lachy> … I think the reason that that ends up being useful than just 
the name of the application is that when you see the UI, you're picking 
an application.

<Lachy> sicking: one problem is trust. It's possible to phish this.

<Lachy> … I could change my icon and title to Bank of America, and fool 
the user.

<Lachy> … It's part of the Chrome UI, so it feels more trustwothy, but 
in reality, it's part of the web content.

<Lachy> Greg: That's a problem with the picker that we had.

<Lachy> … That's one slice of the problem with using the picker that we 
discoverd. I agree there would be a phishing risk.

<Zakim> Arno, you wanted to ask status on intents semantics

<Lachy> Greg: The reason we were using a data URL is that there's a 
problem with web kit.

<Lachy> … It's bug we need to fix.

<npdoty> it seems like a concern that the picker also doesn't make it 
clear what kind of data is being passed along, in addition to it being 
uncertain whom you're passing the data to

<Zakim> timeless, you wanted to comment on that and to comment security 
concerns

<Lachy> timeless: sicking asked about security concerns.All the browsers 
that ship have the ability to ask other services if a website is risky.

<Lachy> … Firefox has the concept of how often you've been to a page.

<Arno> The question was about wether or not there was a work on intent 
semantics, as for example on the edit intent when the intent "returned" 
the data could either be a datablob or a data : URL

<Lachy> … Been to Facebook a lot. Have not been to a phishing site a 
lot. I expect that that would be taken into account by the Ui when 
trying to counter phishing attempts.

<Lachy> Greg: Those are good points.

<Lachy> … Some of those things are valuable to solve the problem.

<Lachy> … We also only accept the API when it's a gesture

<Lachy> ArtB: Are there other implementations?

<Lachy> Greg: I think that someof the problesm I talked about with tabs 
would likely show up with web activities applied to the same kind of use 
cases.

<Lachy> sicking: We've only done it for Firefox OS. Have not shipped yet.

<Lachy> … it's intended to solve exactly the same use cases. Picking, 
sharing, images, etc.

<Lachy> … We do use it internally for things like the camera app. We 
have a button to open your gallery using an intent.

<Lachy> … Other apps can hook into that.

<Lachy> … Likewise, when you have an input type=file, we fire a pick 
event that other apps can hook into.

<shan> s/problesm/problems/

<Lachy> … The goal is definitely to solve the same problem between 3rd 
party apps

<Lachy> mounir: We had an issue in Firefox OS. When you open an app, and 
an app opens another. In that case, we had to know when ???

<mounir> mounir: we had to know if the opener wanted to get a result or not

<Lachy> ArtB: Thank you very much Greg.

<Lachy> ArtB: meeting ajourned.

<mounir> mounir: in the case of a result was expected, we had to handle 
the case of the handler activity being left

<Lachy> RRSAgent: make minutes

<mounir> mounir: to not be in the situation where we actually don't know 
if the result will be sent

<Lachy> RRSAgent: make minutes

<tantek> was it not adjourned?

<timeless> trackbot, end meeting


    Summary of Action Items

*[NEW]**ACTION:*barstow respond to HTMLWG's question re WebApps has a 
strong preference to work on AppCache in WebApps WG [recorded 
inhttp://www.w3.org/2012/10/30-webapps-minutes.html#action02]
*[NEW]**ACTION:*Chaals: Get the ZIP archive proposal on the table as a 
formal work item. [recorded 
inhttp://www.w3.org/2012/10/30-webapps-minutes.html#action01]

[End of minutes]

Received on Tuesday, 30 October 2012 17:40:05 UTC