Web Apps (non-widgets) -- 20 Oct 2008

<chaals> scribenick: anthony

<chaals> scribenick: anthony_

CM: [Chaals introduces himself]

<chaals> AG: Anthony Grasso, editor of SVG Print

<chaals> JS: Jonas Sicking

JS: [Introduce's himself

AB: [Introduces himself]

CW: [Introduces himself]

ABat: [Introduces himself]

EK: [Introduces himself]

AV: [Introduces himself]

WL: [Introduces himself]

CB: [Introduces himself]

JR: [Introduces herself]

NM: [Introduces himself]

IH: [Introduces himself]

CM: Agenda has file upload draft
... progress events will be done tomorrow
... element traversal which we will do today if that's ok DS?

DS: That's fine

CM: DOM3 Events?

DS: Tomorrow?

CM: XHR1 today
... assorted proposals for new work
... timers proposal
... question of whether workers is done here
... we'll have workers for today
... Access control for cross site requests

File Upload

AR: Basically I've been working on the file upload spec
... there's been some feedback from Apple
... mainly just Apple about stating with a more basic set of features
... we can agree on
... there was feedback from Sync APIs from Mozilla
... Google made proposal for Sync APIs
... to obtain segments of files
... to break them up
... there are some concerns with Blog API
... Apple wants no I/O
... I don't think we will be considering Sync APIs for this spec
... I think it will be good to arrive at ASync APIS
... have discussions about file dialog

IH: I think it would be helpful
... to come up with a set of requirements

AR: I didn't get feedback on the list of my requirements

DS: Did you put them in the wiki?

<arve> [Question from the next room: why not a traditional file API?]

AR: They are in the draft

<Adam> http://dev.w3.org/2006/webapi/FileUpload/publish/FileUpload.xhtml

<arun> http://dev.w3.org/2006/webapi/FileUpload/publish/FileUpload.xhtml#requirements

AR: Adam put the right URI
... The next link is the requirements
... a good place to start is the review of these

IH: Do you have in mind things like non-file system access
... e.g. hook up camera to the video element

AR: There isn't a good requirement or illustrated use case

IH: Just want to make sure that you can extend the API
... not so much a use case, more so the long term
... want to be able to take the video camera the video element

DS: It's possible that simply doesn't belong in this family of specs

AR: Maybe possible but I was going to define a Blob interface here
... it would at least be one step closer to that
... plus I was to define the HTML file input element interface which would return a file list

IH: We should interact on that

JS: I feel like the right technical solution will be to have a stream primitive

CM: Note that Opera has requirements to do that already

<karl> rssagent, draft minutes

CM: I've been working on draft requirements

AR: Could this spec define pieces that would be useful to have?

CM: Potentially
... The current proposal for a file API seems limited
... we proposed a more complete file API
... to give recurring access to the file system

<Lachy> which IRC channel is this F2F using today?

<Hixie> this one

<Lachy> good :-)

<chaals> [connectivity here is very flakey so far - so the logs will be very very randomised]

<anne> yay

<MikeSmith> chaals, shepazu: are you minuting on this channel?

<shepazu> MikeSmith: yes, but on a 5 minute break atm

<MikeSmith> OK

IH: - Stream
... - File
... - and file system

NM: If we move to streams
... length is not available
... if you upload things that don't have a length
... It also involves contact from the server
... which are the 3 different requirements

AR: To Google’s credit the XHR extension that allows severs to send back blogs
... this may address your sever side requirement

NM: My concern was about the length.

AB: Any file size limitations?

CM: None. Systems may implement for specific reasons.

NM: For example I could have video running on my camera
... and I could stream that to a server
... there is length

IH: We should treat streams and uploads separately
... focus on finite files
... what do we expose as Blob API.

JS: There is also the first question that Apple has is
... do they want the Blob API
... There is no way of accessing the data

IH: Makes sense to make incremental steps

NM: Instead of completely slitting this up. What about creating temporary files on the fly
... say I want to capture a picture on my camera and I want to upload it.
... Whether it gets saved as a file the user doesn't care.
... Would be useful to have an intermediate for the API.
... For a while the atom protocol has been out one thing not supported in web browsers is
... the ability to upload file from XHR service

AR: In fact that matches in part of what Apple proposes

CM: Seems to be the fundamental thing that everyone wants.
... Use XHR to upload a file

AV: Flikr has an upload widget uses flash. Apples proposal allows replacement of the file object that gives Java control for example.

AR: This gives an overload of the XHR send
... We would be addressing the upload problems in Flikr. Instead of giving another
... binary extension to upload.
... One of the advantages of non-browser based uploads was you can split the file
... up and do chunk uploads. Good for big files.
... for XHR you can see the progress.

IH: What’s the use case

AB: At Boeing we made something that does large file uploads

HS: There are also proxies that do that

IH: You'd want to take a file and split it into max sizes

AR: Which is the use case
... .this brings me back to Step one. I wont be perfectly happy to split out I/O notion of the spec
... Apple made points to strip them out.
... Apple made the further point that wouldn't be happy with Blob as v1.
... I think we should address the main use case which is overloading XHR.
... I haven't gotten technical reasons from Apple about why they are not happy with Blob v1.

CM: My suggestion is given that we are in the stage of being rough draft.
... I think we have fairly clear resolution that we want to save the XHR case and
... get file input working

AV: For the changes to XHR I would prefer those changes to happen in XHR.

AR: I agree with that.

CM: Is everyone in agreement

RESOLUTION: That we are indeed aiming to solve the problem to upload a file using XHR

IH: Is there are reason to have a separate file object and a separate blob object

AR: Yes, the file deals with the file in its entirety

IH: The problem arises when you want to upload a partial file

NM: Not sure what IH's point is the file is not only in bytes but in metadata
... why is it useful for uploading the blob?

JS: A blob is a collection of data where as the file has a content type and file name potentially
... both of which you want to send
... We would send just the byte stream of the file

NM: I almost feel it's undefined to upload bytes without a type.

AR: I agree, as sever app must know what's getting.

NM: The file includes a Blob. There is clearly overlap there

HS: How do you get the media type reliably? From an implementation point of view

JS: We ask the OS. We give it a file and the OS looks it up.

CM: It's necessarily reliable but it's a common thing

AR: NM Said there is some redundancies in the interface
... unless you invoke the slice method on the blob they may match.
... but when you do the properties may vary.

CM: In the requirements we don't have a particular reason for chunk transferring. Can you give a use case for that?

AR: Yes.

<scribe> ACTION: Arun to add the use case for chunk transfers. [recorded in http://www.w3.org/2008/10/20-webapps-minutes.html#action01]

<trackbot> Created ACTION-258 - Add the use case for chunk transfers. [on Arun Ranganathan - due 2008-10-27].

AB: We do both directions up and down.

AR: That's one thing not in this which is a file download of any sort.
... so JS has a better use case for file downloads

JS: For e.g. for Google docs you can open a doc and have it saved to the server. but if you want to save it to the file
... system I believe they upload it to the server and give back a URI

NM: So you are talking about use cases for upload and download?

JS: So this is for the use case where the user wants to download

NM: The webforms group has looked at this. I would prefer we leave this out and leave it to forms.

AR: So HTML5 has resolved to take on Webforms. This may be resolved in HTML5?

JS: My concern is I don't think it's very form related.

IH: Most data comes from contentEditable

JS: I think that if we are created a limited v1 spec that I think download can go into v2

AR: But it can be a use case/requirement

JS: If the forms people have looked at this maybe we should look at what they've done. If they have
... a good solution we should reference that.

<scribe> ACTION: Arun to add a use case for file download [recorded in http://www.w3.org/2008/10/20-webapps-minutes.html#action02]

<trackbot> Created ACTION-259 - Add a use case for file download [on Arun Ranganathan - due 2008-10-27].

CM: Is anyone desperate to have it v1 spec?

All: None

AR: I believe we can wrap up the discussion
... by saying that unless a good technical argument is put forward by Apple
... I think v1 should include a def of HTML5 file input element, blob as an async
... I'm open to removing file dialog
... If anyone has any objections regarding Google's blob API speak now

JS: Right now I'd like to see the sync functionality as async

CM: Summary, to have the whole thing as a blob API, have the whole thing as ASync, XHR extension and HTML5 input element

IH: I'm fine with having these features
... I think we should make it simpler

AR: There is a method for removing files
... can you give me a technical reason?

IH: To make it simpler

CM: What's the complication of removing a file?

IH: Unless we can absolutely defending having a feature
... we should consider dropping it

AV: Seems like a better approach

AR: I can remove the remove

CM: Along with file download
... Opera still wants to see file System

IH: That should also be separate spec like streaming

CM: Or be v2

DS: Should put future products in tracker

<scribe> ACTION: Chaals to Provide a use case for file system access [recorded in http://www.w3.org/2008/10/20-webapps-minutes.html#action03]

<trackbot> Created ACTION-262 - Provide a use case for file system access [on Charles McCathieNevile - due 2008-10-27].

CM: With that I think we have enough to go forward
... lets drop the proposal to publish the current draft
... and you'll do up a new one which you'll propose for publishing

<chaals> scribeNick: sicking

new work

CM: current proposals are; stuff from NM, timer API from mjs, workers from whatwg, window API

AR: with worker threads current proposal is to move it from whatwg to w3c to allow parties that prefer working with w3c can contribute

HI: workers are part of w3c

<Hixie> http://dev.w3.org/html5/workers/Overview.html

AR: propose to make it a formal work item

CM: we need approval from AC
... takes not long
... need draft, editor
... hixie, you wanna be editor?

HI: I'm already editing the spec, so I don't mind changing the SotD to say "WebApps WG" instead of "HTMLWG"!

DS: the reason we need AC approval was that people was worried that webapps was taking on too much
... we need usecase and requirements

<chaals> s/roxxorz/I'm already editing the spec, so I don't mind changing the SotD to say "WebApps WG" instead of "HTMLWG"/

DS: how long will AC review take?

AC: with this work item it should not take long. 3 weeks i believe

DS: we can start work before AC approves

CM: given that we have editor, anyone think we should not take it on?

RESOLUTION: we will take it to the AC and ask permission to add to charter

DS: we should ask the html wg for permission

CW: as a chair i've said before that i think this is a good idea

CM: it's in our charter that we need to ask AC, but there is no formal process to do so. We'll figure it out

<nrmehta> http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0104.html

NM: i have proposal for seamless online/offline apps

<arun> Wants it noted that WorkerThreads was originally requested as a WebApps Work Item, along with Content Security Policy: http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/0416.html

NM: objective is for applications to be able to access data when network is not available. There are a few use cases in draft

<arun> While WorkerThreads *may* move here as a result of request by Chairs, Content Security Policy still remains TBD (including within Mozilla)

NM: main one is traveling sales guy to access data when not online
... html5 proposes new data storage mechanism, such as localstorage or sql db

<anne> BITSY (with correct MIME type): http://html5.org/temp/2008/bitsy.xhtml

NM: this proposal does not provide a new storage mechanism
... you can use XHR to load and store data
... you can also use hyper link, form submission, resource links (such as <link>)
... caveat is that the data needs to be linked to an atom feed
... intention is not to act as a replacement to html5 spec
... it's mainly intended for data, not resources (although it could be used for that)
... this proposal provides a way accessing data when offline, and for data to be submitted to server when going back online

AR: does the builder object throw an error if a resource is not available and user is offline?

NM: in such a case the resource will not be available

AR: have you looked at rules for XHR with regards to access to headers

NM: cookie header is allowed to be set in the builder object

AR: are there cross site restrictions

NM: We'd like to allow cross domain access, but we have not thought about that so far

AV: can we back out from technical details and look at higher level

NM: i'd like to able to look at existing objects when offline, and like to be able to change resources while offline
... if a resource is not available at request time, request is stored and replayed when resource becomes available

CM: at a very high level this uses atompub to define a synchronization mechanism
... instead of having to implement your own synch mechanism yourself you use atompub and then let the browser do synchronization for you

NM: html5 has mechanism for storing data. Does not have ability to cache resources

IH: html5 has offline cache

CW: what is the status? It says copyright all rights reserved
... sockets does allow this functionality. It's super powerful but also super hard
... outlook guys have worked for 10 years to make offline exchange working. It works great now but it was really hard

CM: w3c has process for submitting members only stuff

CW: so is this a member submission?
... if it says all rights reserved oracle our guys can't read it

NM: oracle will not have problems making this public

CW: please send it to the list and say that it's a member submission. That'll take care of the license

<chaals> ACTION: Nikunj to provide a legalese and process-friendly version of the proposal [recorded in http://www.w3.org/2008/10/20-webapps-minutes.html#action04]

<trackbot> Created ACTION-263 - Provide a legalese and process-friendly version of the proposal [on Nikunj Mehta - due 2008-10-27].

JS: very fair, we gave microsoft the same crap when we got feedback under a license

<Zakim> CWilso, you wanted to point out 1) IP 2) "sync is hard"

NM: since sync is hard we should have functionality for it

CW: we need to look at scenarios before going forward since we will get lots of questions
... we should define use cases clearly

NM: we have not included indexing for example

IH: my concern is that something like this would be a solution for a small set of problems. Not even 50%. Browsers generally want to address things more like 80% of the use cases

NM: we should have something for atompub. If 80% of atompub are solved by this then this is good enough for us

<Zakim> chaals, you wanted to say that this appears to provide a solution for simple applications, supporting small-time developers, although not enough for really serious applications

IH: this might be implementable using a JS library backed by XHR

<arun> +1 IH, modulo access to requests from within script

NM: current specs does now allow syncing in background

IH: workers might add that ability, though it scares me

<CWilso> CM: "idiots like me"

CM: it appears to lower bar for developers to have this functionality
... if we decide to take this on, we need to look at what the html5 wg

NM: a number of these things are possible to do with existing specs. However there are not conclusive evidence that there is. we did a lot of research on existing specs but wasn't able to find conclusive evidence. If this is interesting enough we probably need to extend specs

<Zakim> CWilso, you wanted to say: XHR2 + localStorage + SQL storage + this + offline/cache control: whither?

NM: for example if the application updates data, there is no mechanism for making that data available to the app itself

CW: it is likely that more advanced use cases will roll their own solution based on localstorage, XHR2, etc etc. It's important that we think of this at a continuum so that it integrates with other pieces
... i had an action item to look at where offline is going. I was at the time thinking it should stay in html5, but less sure now

DS: hixie, what is your opinion on splitting this up into a work item in this WG, with a stub in HTML

IH: right now integration points are: navigating a browsing context, and when doing general network activity

<Hixie> ...which is defined just in the appcache step

JS: there is also the markup for declaring manifests

IH: so not the first thing i'd break out, but not the last either

AR: if we were to consider this, we should check how much is already covered by existing spec. And we'd need use cases

DS: to me this sounds like something that is a larger task that belongs in a larger group, such as a task force or separate WG

CW: i see mixed bag with having separate WG
... i'd like a place where the discussion takes place where i can point people
... i wouldn't want to pull everything out from html5 since it's hard to pull too far apart

DS: i can deal with the logistics

CM: can i get more work to give to DS plez, kthnx
... so he can not do it
... simplest way to move forward is to keep in webapps group
... needs to be coordinated with html wg
... CW, can you follow discussion for webapps

CW: having it in same list is a bit concerning due to traffic volumes

JS: I'd like a separate list too

CM: NM, are you prepared to do the work?

NM: yes

<chaals> AvK: Want to see the things that can't be done with libraries

<chaals> JS: Think this is something we should look at, but this is a non-trivial problem. E.g. suspect there will be lots of discussions on whether AtomPub is the right thing, etc...

<chaals> JS: also concerned that we may get a 30% solution....

NM: if we approach it as a need to evolve the primitives such that this can be built as a library then that might be a good solution

IH: agree

AV: agree

JS: agree

CM: so sounds like there is agreement to keep looking at problem. First step being gather more use cases, NM has action item to submit some of those

<chaals> ACTION: Nikunj to provide more use cases and explanation of why we need something like bitsy [recorded in http://www.w3.org/2008/10/20-webapps-minutes.html#action05]

<trackbot> Created ACTION-264 - Provide more use cases and explanation of why we need something like bitsy [on Nikunj Mehta - due 2008-10-27].

CM: do we want to talk about timers?

AV: there are proposals to simply lower the minimum delay from 10ms to 4ms which might address use cases
... however we might need to discuss moving setTimeout etc to this WG

JS: who would be editor

AV: opera has a proposed editor

IH: i'd love to see it removed from the html5 spec

CM: shall we resolve to shift spec to webapps

<arun> +1 AR

IH: i support it as long as there is an editor

RESOLUTION: will start process to get it added as work item for WG

<chaals> [for all of you reading the logs: "resolutions" here are subject to being published in the minutes, and not raising objections from the group, since not everyone is at this meeting]

window object

CM: we need an editor
... it's really really really hard to edit
... you must be insane to do so
... anyone interested?

IH: what is the advantage of having it as a separate spec
... i used to think it's a good idea, but less sure at this point
... I've tried to write the html5 spec such that svg can use it. By defining interactions for for example properties with same name

CM: i'll talk with svg guys and see if anyone is prepared to do the work

IH: i want svg to be able to use it. So tell them if there is anything i can do to help them i'll be happy to do so

CM: anything more we should bring up?

AR: mozilla would like to submit content security policy, but it's not ready at this point. But as a heads up, we'll do so in the future

lunch

will we have it, and will it taste yummy

<chaals> We will be back here at 14h30 french time. If you want to talk to another group, before then is a good time to pick

<DanC_lap> (found timbl's proposal http://lists.w3.org/Archives/Public/www-tag/2008May/0165.html )

<DanC_lap> hierarchical... check.

<DanC_lap> e.g. <imsg src="../over/there/in/the/zip/file" />

<DanC_lap> e.g. <img src="../over/there/in/the/zip/file" /> rather

<DanC_lap> expose... not sure.

<DanC_lap> outside... not sure

<DanC_lap> conflict... not sure

<hendry> is the widget stuff happening in group 1 or 2?

<hendry> and where is the back channel please

<DanC_lap> (I wonder if http://engine/widget/path is analagous to http://example.com/widgets/2007/blink-01.zip/contents/chrome/js/blink.js . not sure what /engine/ is)

<DanC_lap> "no standard" applies to widget: too, right?

<DanC_lap> hendry, widget stuff is in A (dunno which is 1 vs 2)

<hendry> DanC_lap: wondered if i could drop in as an observer for an hour. can't see art online to clear it.

<DanC_lap> hendry, I just learned #wam is the channel for the widget stuff; ArtB is there

<hendry> DanC_lap: thanks!

<gsnedders> I guess I should return to the room

<Adam> scribeNick: Adam

Element Traversal

<Lachy> just so this is recorded somewhere, even though it's not the topic yet, the remaining issues for selectors api are:

<Lachy> 1. Add last 40 emails to the disposition of comments

<Lachy> 2. deal with one issue regarding the feature string/

<Lachy> 3. Respond to other emails saying that the issues are postponed till v2.

DS: you can skip over text nodes and just navigate the tree by the elements

wrote some tests, has been CR

<chaals> [chaals uploaded a new progress events draft: http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.22 for your enjoyment]

DS: wrote some tests, has been CR
... html 4, xhtml, svg versions of the files, tested in opera and batik which is an svg toolkit
... each test passed by both opera and svg toolkit,
... would like to propose moving from CR to PR

JS: sold
... test cases do have some errors
... etnamespace.svg test

<smaug> chaals: could you change loaded and total to unsigned long long?

<chaals> [smaug, I think I did that]

AV: would like to see it test

<shepazu> http://dev.w3.org/2006/webapi/ElementTraversal/tests/

<smaug> "readonly attribute unsigned long loaded;"

<sicking> http://dev.w3.org/2006/webapi/ElementTraversal/tests/et-namespace.svg

<chaals> [ah. found it... Better edited version coming soon]

DS: were very basic test

JS: are you testing dynamic stuff

DS: no

JS: will try to update his test, does some dynamic stuff
... haven't tested any of the HTML test

DS: should see the word pass if they pass

AV: where is the function init test being called
... doesn't seem to run the script at all?

DS: thought other people wanted some things for version 2

<anne> ed_fr, I pointed out as much

<anne> ed_fr, the tests suck, for lack of a better word

CM: we believe when the tests are fixed they'll pass, that their modular, bugs identified, assuming when the tests are fixed, and the browsers pass it we are resolved to PR status

<chaals> RESOLUTION: Subject to the identified bugs in tests being fixed, and implementations still passing, we will request PR status for Element Traversal

AV: still think its not necessary to child element counts

DS: likes it

<Hixie> is the next topic xhr?

AV: whats wrong with children length

<Hixie> thanks

<anne> children.length is two characters shorter than childElementCount

DS: it was svg to tiny user agent with mobile devices that don't already have node list interface
... feedback from user agent vendors didn't want to do node list, that operation was significantly more costly to them
... could be put in v2

JS: totally bogus but not going to argue about it

AV: agree it's bogus

CM: if we stop talking about this we'll have more time to talk about v2

JS: for the sake of moving on

DS: moving on to v2

<chaals> ACTION: Doug to fix the tests for Element Traversal and make the implementation report [recorded in http://www.w3.org/2008/10/20-webapps-minutes.html#action06]

<trackbot> Sorry, amibiguous username (more than one match) - Doug

<trackbot> Try using a different identifier, such as family name or username (eg. dstamper, schepers)

<chaals> ACTION: schepers to fix the tests for Element Traversal and make the implementation report [recorded in http://www.w3.org/2008/10/20-webapps-minutes.html#action07]

<trackbot> Created ACTION-266 - Fix the tests for Element Traversal and make the implementation report [on Doug Schepers - due 2008-10-27].

CM: do we need AC approval to do v2

AV: seems unnecessary

<chaals> ACTION: schepers to check if we need approval to work on Element Traversal, and start working on v. 2 [recorded in http://www.w3.org/2008/10/20-webapps-minutes.html#action08]

<trackbot> Created ACTION-267 - Check if we need approval to work on Element Traversal, and start working on v. 2 [on Doug Schepers - due 2008-10-27].

AV: no need for an email to 400 people for people to say yes

DS: doesn't agree
... want to let them know we're doing work

JS: thought wanted next-previousElementSibling on text nodes
... thougth somebody asked for that
... point was should be in v2 and not in a separate space

<chaals> RESOLUTION: We want the new version with node lists etc...

XHR

AV: was comment made on last call, made some disposition of comments
... need some kind of wg agreement
... HS mentioned might be something in html5
... actually doing the XHR actually integrate in to the event loop

CM: why do we want to make this change

HS: if you do a set timeout or trigger or an async event it defines in what order the events will fire

AV: that is a part that has never been standardized but html5 does that
... a few hours to do

HS: net change spec will say fire task

AV: that was the only to change in v1, v2 has other oustanding issues

JS: at the risk of starting a war, what were the prospects of ie implementing the spec
... feels the pain of it breaking stuff in IE
... is there a strategy here to get everyone on the same page

CW: great guestions, i don't know, last understanding was there where things being done differently, not going to be able to change it in the near term, not say we shouldn't or it's not the right thing to do

JS: what is the probabity of it eventually being implemented

CW: it's not impossible

JS: is there feedback from MS on things that should be changed in the spec

ABate: does have a document that he has the action to review that but not sure what it has

CM: seems like there are least some changes to spec so not going to do a last call today

AV: don't have any open issues noted
... some issue with char set that he doesn't have the detail down for yet

JS: is afraid of changing the content type at all
... why is that in the spec

AV: somebody argued for it
... so the server could figure out whats going on

<chaals> [ http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.23 available, with better editing (Thanks Smaug)]

JS: personally wouldn't might waiting for that until XHR2

AV: doesn't want to add a dom attribute
... to address it

JS: alternative is to have a separate header

<smaug> [chaals: still "readonly attribute unsigned long loaded;" ;) ]

<smaug> [same for .total]

AV: i really hate char sets
... could leave it undefined, i don't like it, could say sending char set is a violation

<chaals> [d'oh. /me curses whitespace and fixes it AGAIN...]

AV: could let MS and JS to go back for feedback review

<scribe> ACTION: JS to review if char set is something that can be removed [recorded in http://www.w3.org/2008/10/20-webapps-minutes.html#action09]

<trackbot> Sorry, amibiguous username (more than one match) - JS

<trackbot> Try using a different identifier, such as family name or username (eg. jsoref, jsicking)

<nrmehta> This is a common problem with charsets on XML and HTTP http://www.xml.com/pub/a/2004/07/21/dive.html

<scribe> ACTION: jsicking to review if char set is something that can be removed [recorded in http://www.w3.org/2008/10/20-webapps-minutes.html#action10]

<trackbot> Created ACTION-268 - Review if char set is something that can be removed [on Jonas Sicking - due 2008-10-27].

AV: did we want to go through comments for disposition

HS: should go through the ones where the commentor is not happy with the response

<anne> http://dev.w3.org/2006/webapi/XMLHttpRequest/disposition-of-comments-2

<DanC_lap> [15:37] <trackbot> ACTION-187 -- Dan Connolly to talk with TimBL about install-time names for widgets -- due 2008-10-27 -- OPEN

<DanC_lap> [15:37] <trackbot> http://www.w3.org/2001/tag/group/track/actions/187

<chaals> [aah, smaug were you looking at http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.24 ? I may have pasted the wrong link in before ;) ]

CM: don't have to look at all the dispositions from previous last call

AV: #7 is rejected
... several headers are being blocked on being sent

<smaug> [chaals: great, thanks. Will change long -> long long in mozilla]

AV: he agrees with some being blocked but not others

DS: have other people chimed in on that thread, is there some sort of

HS: can't allow the user agent is dodgy

<anne> http://lists.w3.org/Archives/Public/public-webapi/2008May/0408.html

AV: some reason why referrer was on the block list

JS: i don't think we block it yet do we

DS: he is not an implementor
... does anybody in the group disagree with AV
... if the vendors are all ok then this is a polite disagree

AV: was about the dependancy on html 5

CM: lots of people said strip the reference to html5

AV: they suggested to copy it all in, that was not the best way to go, would be huge

DS: i requested the spec leave everything up to the host language

AV: what is a host language?

DS: if you're using a script it's the host language

HS: bigger problem is you may not have a host language

DS: that would be the host language

HS: then that would be the host language

AV: some definitions could be inlined

HS: there is a reference from html 5 to xhr in that part of the spec

JS: can do cross domain at the browser chrome

AV: could be a should do it

JS: why do we need to specifiy that xhr is same origin

AV: still need to define origin

CM: would suggest that things that can be inlined are better off inlined
... makes the case these things are massive complicated stuff makes the case easier to argue

<scribe> ACTION: chaals to look through the references to see what can reasonably inlined [recorded in http://www.w3.org/2008/10/20-webapps-minutes.html#action11]

<trackbot> Created ACTION-269 - Look through the references to see what can reasonably inlined [on Charles McCathieNevile - due 2008-10-27].

AV: is ok with doing this
... one issue with setting second arg to null

JS: null handling is behavior is undefined

<Hixie> chaals, do you remember which section of the process defines this restriction on references? i can't find it (i wanted to see what the exact wording is)

JS: have 2 options, it gives special behavior for null, or do nothing

AV: default is stringify to default

JS: i think should leave it at the default

HS: can't just leave it the default

JS: a little afraid of doing any behavior even though it sounds somewhat reasonable to do

CM: julian is the only one that wants to remove the header

NM: value null is issue if you stringify it
... there are no sementics defined for the value null
... agree with JS

<chaals> Hixie, can't recall off hand.

HS: would much rather browser turn it in to empty string

JS: would like it be explicitly undefined here

AV: thats not possible

<nrmehta> null causes more problems if one were to call setRequestHeader multiple times to set values of the same header, in which case the value null will be serialized in to the concatenated header value

JS: things follow what web idl says to do

AV: i don't think we should do that

<Hixie> sicking, http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/Overview.html?content-type=text/html;%20charset=utf-8

<Hixie> sicking: search for the third definition of "open(" in the IDL

<Hixie> and compare the second and the third arguments

NM: in opinion, thinks it's in violation of the spec

CM: should we do what julian says and remove the header? in any case no, not goign to remove the headers

Resoultion: not going to remove the header

Resolution: not going to remove the header

<karl> Hixie, chaals there is no formal requirement in the process document, but

taking a break

<karl> if you go to http://www.w3.org/2005/08/online_xslt/xslt?xmlfile=http://www.w3.org/2005/08/01-transitions.html&xslfile=http://www.w3.org/2005/08/transitions.xsl&docstatus=pr-tr

<karl> there is

<karl> Evidence that dependencies with other groups met (or not)

<karl> * Does this specification have any normative references to W3C specifications that are not yet Proposed Recommendations? Note: In general, documents do not advance to Recommendation with normative references to W3C specifications that are not yet Recommendations.

<karl> * Is there evidence that additional dependencies related to implementation have been satisfied?

<Hixie> hm, interesting

<Hixie> so it's not a process issue?

<karl> not realy, it is more that if a document has a normative dependency on another one. it is risky.

<karl> the referenced document can change

<karl> changing then the conformance requirement.

<karl> I guess it is case by case

<karl> and has to be strongly documented when going to the transition call.

<Hixie> very interesting

<Hixie> thanks!

<karl> you're welcome

<CWilso> scribenick: cwilso

XHR still

JS: HTTP-only key issue. thinks moz is going to block set-cookie header entirely.

<Hixie> http://dev.w3.org/2006/webapi/XMLHttpRequest/disposition-of-comments-2

AVK: you're suggesting not getting any value back for setcookie? That would be cool...

JS: yes, we pretend like it's not there. There's some concern about breakage, but seems unlikely.

IH: realm seems ok, since you can get it from the url.

NM: list of headers is static... but there's nothing here that requires browser impls to sync with IETF list of headers - what happens if someone defines a new header?

JS: don't do that. Or use Sec-.

AVK: Next issue: forms wg requested making instantiating an XHR object more abstract (e.g. don't need a Window object)

JS: XHR would make sense for Flash, but they don't have Window.

AVK: why do we care about Flash

JS: seems like we should make this possible

(discussion of proprietary platforms using XHR ensues)

IH: should just make the magic sentence non-normative

<scribe> ACTION: Jonas Sicking to send email: Make non-normative suggestion that Window object can be omitted (for situations with no Window) [recorded in http://www.w3.org/2008/10/20-webapps-minutes.html#action12]

<trackbot> Created ACTION-270 - Sicking to send email: Make non-normative suggestion that Window object can be omitted (for situations with no Window) [on Jonas Sicking - due 2008-10-27].

AVK: That's it for XHR1

JS: XHR1 says to send the same events whether you're synchronous or async. Mozilla doesn't currently send any events in sync case. Is the spec right here?

AVK: Yes. I have tests for this and moz fails them.

<shepazu> Element Traversal implementation report: http://dev.w3.org/2006/webapi/ElementTraversal/tests/report/et-implementationReport.html

AVK: the events are fired synchronously.

[discussion ensues of whether this is true]

IH: why can't you skip events?

JS: because we put lots of other stuff in the event loop, including the UI

IH: from my point of view, that's a bug

JS: from my point of view, it's a feature. :)

IH: we can (should?) change the spec to explicitly state that we keep pumping the event loop during sync XHR

AVK: will leave spec as is
... that concludes addressing the comments
... will update Disposition of comments.

Selectors api

<Lachy> http://dev.w3.org/2006/webapi/selectors-api/

LH: spec update is mostly done, almost ready to go to 2nd LC. About 40 emails to go through for Disposition of Comments.

Last issue is the Feature string (hasFeature)

LH: rejected request to use XHTML syntax for example
... adding "scope" - moved to v2
... [number of issues relating to NSResolver, which was dropped]

MS: So three weeks or so for a new LC draft?

JS: defends namespaces
... I think we'll end up adding back NSResolver as it was
... but I'm fine with it not being in v1.

LH: need to fix up the list of acknowledgements.

AVK: proposes to publish LC again

hearing no objections, MS says:

<MikeSmith> RESOLUTION: Publish another LC WD for Selectors API, with plan to do 3-week LC period.

MS: tomorrow: AC, XHR2, Progress Events

Moving forward with Window Object spec?

IH: Window should contain browsing context and navigating context

yeah, something like that.

MS: seems like we should be done for the day?

adjourned

- DRAFT -

Web Apps (non-widgets)

20 Oct 2008

Attendees

Contents