07:18:49 <RRSAgent> RRSAgent has joined #webapps
07:18:49 <RRSAgent> logging to http://www.w3.org/2008/10/20-webapps-irc
07:19:01 <Carmelo> Carmelo has joined #webapps
07:20:04 <chaals> Agenda: http://www.w3.org/2008/webapps/wiki/WebAppsMandelieuAgenda
07:20:14 <chaals> Meeting: Web Apps (non-widgets)
07:20:45 <marcos> marcos has joined #webapps
07:21:13 <chaals> scribenick: anthony
07:21:19 <anthony> anthony has left #webapps
07:21:25 <dino> dino has joined #webapps
07:21:50 <anthony_> anthony_ has joined #webapps
07:24:27 <chaals> scribenick: anthony_
07:24:58 <anthony_> CM: [Chaals introduces himself]
07:25:40 <chaals> AG: Anthony Grasso, editor of SVG Print
07:25:56 <chaals> JS: Jonas Sicking
07:25:58 <anthony_> JS: [Introduce's himself
07:26:00 <dino> dino has joined #webapps
07:26:16 <anthony_> AB: [Introduces himself]
07:26:26 <anthony_> CW: [Introduces himself]
07:27:04 <karl> karl has joined #webapps
07:27:28 <arun> arun has joined #webapps
07:28:34 <kaz> kaz has joined #webapps
07:28:36 <anthony_> ABat: [Introduces himself]
07:28:43 <anthony_> EK: [Introduces himself]
07:28:45 <kaz> kaz has left #webapps
07:28:54 <anthony_> AV: [Introduces himself]
07:29:03 <anthony_> WL: [Introduces himself]
07:29:12 <anthony_> CB: [Introduces himself]
07:29:20 <anthony_> JR: [Introduces herself]
07:29:26 <anthony_> NM: [Introduces himself]
07:29:38 <anthony_> IH: [Introduces himself]
07:29:44 <anthony_> CM: Agenda has file upload draft
07:30:11 <anthony_> ... progress events will be done tomorrow
07:30:22 <anthony_> ... element traversal which we will do today if that's ok DS?
07:30:28 <anthony_> DS: That's fine
07:30:34 <anthony_> CM: DOM3 Events?
07:30:37 <anthony_> DS: Tomorrow?
07:31:01 <anthony_> CM: XHR1 today
07:31:11 <anthony_> ... assorted proposals for new work
07:31:17 <anthony_> ... timers proposal
07:31:29 <anthony_> ... question of whether workers is done here
07:31:36 <anthony_> ... we'll have workers for today
07:31:46 <anthony_> ... Access control for cross site requests
07:32:19 <anthony_> Topic: File Upload
07:32:49 <anthony_> AR: Basically I've been working on the file upload spec
07:32:55 <anthony_> ... there's been some feedback from Apple
07:33:09 <anthony_> ... mainly just Apple about stating with a more basic set of features
07:33:12 <anthony_> ... we can agree on
07:33:25 <anthony_> ... there was feedback from Sync APIs from Mozilla
07:33:34 <anthony_> ... Google made proposal for Sync APIs
07:33:38 <anthony_> ... to obtain segments of files
07:33:46 <anthony_> ... to break them up
07:33:59 <anthony_> ... there are some concerns with Blog API
07:34:23 <anthony_> ... Apple wants no I/O
07:34:36 <anthony_> ... I don't think we will be considering Sync APIs for this spec
07:34:45 <anthony_> ... I think it will be good to arrive at ASync APIS
07:34:59 <anthony_> ... have discussions about file dialog
07:35:13 <anthony_> IH: I think it would be helpful 
07:35:18 <anthony_> ... to come up with a set of requirements
07:35:27 <anthony_> AR: I didn't get feedback on the list of my requirements
07:35:33 <anthony_> DS: Did you put them in the wiki?
07:35:33 <arve> [Question from the next room: why not a traditional file API?]
07:35:39 <anthony_> AR: They are in the draft
07:35:43 <Adam> http://dev.w3.org/2006/webapi/FileUpload/publish/FileUpload.xhtml
07:35:55 <arun> http://dev.w3.org/2006/webapi/FileUpload/publish/FileUpload.xhtml#requirements
07:35:58 <anthony_> AR: Adam put the right URI
07:36:06 <anthony_> ... The next link is the requirements
07:36:14 <anthony_> ... a good place to start is the review of these
07:36:36 <anthony_> IH: Do you have in mind things like non-file system access
07:36:45 <anthony_> ... e.g. hook up camera to the video element
07:36:59 <anthony_> AR: There isn't a good requirement or illustrated use case
07:37:09 <chaals> q+
07:37:20 <anthony_> IH: Just want to make sure that you can extend the API
07:37:30 <anthony_> ... not so much a use case, more so the long term
07:37:42 <anthony_> ... want to be able to take the video camera the video element
07:38:14 <anthony_> DS: It's possible that simply doesn't belong in this family of specs
07:38:26 <anthony_> AR: Maybe possible but I was going to define a Blob interface here
07:38:33 <anthony_> ... it would at least be one step closer to that
07:38:36 <Zakim> Zakim has joined #webapps
07:38:58 <anthony_> ... plus I was to define the HTML file input element interface which would return a file list
07:39:07 <anthony_> IH: We should interact on that
07:39:33 <anthony_> JS: I feel like the right technical solution will be to have a stream primitive
07:39:47 <nrmehta> q+
07:39:49 <karl> RRSAgent, make log public
07:39:52 <anthony_> CM: Note that Opera has requirements to do that already
07:40:06 <karl> rssagent, draft minutes
07:40:26 <karl> rrsagent, draft minutes
07:40:26 <RRSAgent> I have made the request to generate http://www.w3.org/2008/10/20-webapps-minutes.html karl
07:40:40 <anthony_> ... I've been working on draft requirements
07:40:58 <anthony_> AR: Could this spec define pieces that would be useful to have?
07:41:01 <anthony_> CM: Potentially
07:41:15 <anthony_> ... The current proposal for a file API seems limited
07:41:20 <anthony_> ... we proposed a more complete file API
07:41:31 <anthony_> ... to give recurring access to the file system
07:56:17 <tlr> tlr has joined #webapps
07:56:38 <kapyaho> kapyaho has joined #webapps
07:57:29 <dino> dino has joined #webapps
07:57:33 <karl> karl has joined #webapps
07:58:11 <arve> arve has joined #webapps
07:58:47 <dino> dino has joined #webapps
07:59:16 <wonsuk> wonsuk has joined #webapps
08:00:12 <Lachy> Lachy has joined #webapps
08:01:27 <Lachy> which IRC channel is this F2F using today?
08:01:47 <Hixie> this one
08:01:51 <gsnedders> gsnedders has joined #webapps
08:01:59 <Lachy> good :-)
08:02:20 <MikeSmith> MikeSmith has joined #webapps
08:05:09 <dino_> dino_ has joined #webapps
08:05:46 <CWilso> CWilso has joined #webapps
08:06:16 <arun> arun has joined #webapps
08:06:20 <chaals> chaals has joined #webapps
08:06:50 <chaals> [connectivity here is very flakey so far - so the logs will be very very randomised]
08:07:00 <Adam> Adam has joined #webapps
08:07:08 <jreyes> jreyes has joined #webapps
08:07:13 <Carmelo> Carmelo has joined #webapps
08:07:18 <shepazu> shepazu has joined #webapps
08:07:41 <sicking> sicking has joined #webapps
08:08:00 <nrmehta> nrmehta has joined #webapps
08:08:24 <adrianba> adrianba has joined #webapps
08:09:25 <anne> anne has joined #webapps
08:10:24 <anne> yay
08:11:11 <MikeSmith> chaals, shepazu: are you minuting on this channel?
08:11:38 <shepazu> MikeSmith: yes, but on a 5 minute break atm
08:11:46 <MikeSmith> OK
08:15:47 <marcos> marcos has joined #webapps
08:17:26 <anthony_> anthony_ has joined #webapps
08:18:09 <dino> dino has joined #webapps
08:29:45 <nrmehta> nrmehta has joined #webapps
08:30:15 <Kangchan> Kangchan has joined #webapps
08:31:12 <anthony_> IH: - Stream
08:31:16 <anthony_> ... - File
08:31:21 <anthony_> ... - and file system
08:31:30 <anthony_> NM: If we move to streams
08:31:32 <anthony_> ... length is not available
08:31:32 <anthony_> ... if you upload things that don't have a length
08:31:33 <anthony_> ... It also involves contact from the server
08:31:35 <anthony_> ... which are the 3 different requirements
08:31:37 <anthony_> AR: To Google’s credit the XHR extension that allows severs to send back blogs
08:31:39 <anthony_> ... this may address your sever side requirement
08:31:41 <anthony_> NM: My concern was about the length.
08:31:54 <anthony_> AB: Any file size limitations?
08:32:00 <anthony_> CM: None. Systems may implement for specific reasons.
08:32:07 <anthony_> NM: For example I could have video running on my camera
08:32:09 <anthony_> ... and I could stream that to a server
08:32:10 <anthony_> ... there is length
08:32:13 <anthony_> IH: We should treat streams and uploads separately
08:32:15 <anthony_> ... focus on finite files
08:32:17 <anthony_> ... what do we expose as Blob API.
08:32:21 <anthony_> JS: There is also the first question that Apple has is
08:32:23 <anthony_> ... do they want the Blob API
08:32:25 <anthony_> ... There is no way of accessing the data
08:32:30 <anthony_> IH: Makes sense to make incremental steps
08:32:37 <anthony_> NM: Instead of completely slitting this up. What about creating temporary files on the fly
08:32:38 <anthony_> ... say I want to capture a picture on my camera and I want to upload it.
08:32:40 <anthony_> ... Whether it gets saved as a file the user doesn't care.
08:32:42 <anthony_> ... Would be useful to have an intermediate for the API.
08:32:43 <anthony_> ... For a while the atom protocol has been out one thing not supported in web browsers is
08:32:45 <anthony_> ... the ability to upload file from XHR service
08:32:47 <anthony_> AR: In fact that matches in part of what Apple proposes
08:32:49 <anthony_> CM: Seems to be the fundamental thing that everyone wants.
08:32:51 <anthony_> ... Use XHR to upload a file
08:33:20 <Adam> Adam has joined #webapps
08:35:12 <Kangchan> Kangchan has left #webapps
08:35:57 <arve> arve has joined #webapps
08:36:45 <anthony_> AV: Flikr has an upload widget uses flash. Apples proposal allows replacement of the file object that gives Java control for example.
08:36:52 <anthony_> AR: This gives an overload of the XHR send
08:36:54 <anthony_> ... We would be addressing the upload problems in Flikr. Instead of giving another
08:36:56 <anthony_> ... binary extension to upload.
08:36:58 <anthony_> ... One of the advantages of non-browser based uploads was you can split the file
08:36:59 <anthony_> ... up and do chunk uploads. Good for big files.
08:37:01 <anthony_> ... for XHR you can see the progress.
08:37:03 <anthony_> IH: What’s the use case
08:37:04 <anthony_> AB: At Boeing we made something that does large file uploads
08:37:06 <anthony_> HS: There are also proxies that do that 
08:37:07 <anthony_> IH: You'd want to take a file and split it into max sizes
08:37:09 <anthony_> AR: Which is the use case
08:37:12 <anthony_> .. .this brings me back to Step one. I wont be perfectly happy to split out I/O notion of the spec
08:37:14 <anthony_> ... Apple made points to strip them out.
08:37:15 <anthony_> ... Apple made the further point that wouldn't be happy with Blob as v1.
08:37:17 <anthony_> ... I think we should address the main use case which is overloading XHR.
08:37:19 <anthony_> ... I haven't gotten technical reasons from Apple about why they are not happy with Blob v1.
08:37:21 <anthony_> CM: My suggestion is given that we are in the stage of being rough draft.
08:37:23 <anthony_> ... I think we have fairly clear resolution that we want to save the XHR case and
08:37:25 <anthony_> ... get file input working
08:37:26 <anthony_> AV: For the changes to XHR I would prefer those changes to happen in XHR.
08:37:28 <anthony_> AR: I agree with that.
08:37:30 <anthony_> CM: Is everyone in agreement
08:37:32 <anthony_> RESOLUTION: That we are indeed aiming to solve the problem to upload a file using XHR
08:37:33 <anthony_> IH: Is there are reason to have a separate file object and a separate blob object
08:37:35 <anthony_> AR: Yes, the file deals with the file in its entirety
08:37:36 <anthony_> IH: The problem arises when you want to upload a partial file
08:37:38 <anthony_> NM: Not sure what IH's point is the file is not only in bytes but in metadata
08:37:41 <anthony_> ... why is it useful for uploading the blob?
08:37:42 <anthony_> JS: A blob is a collection of data where as the file has a content type and file name potentially
08:37:44 <anthony_> ... both of which you want to send
08:37:45 <anthony_> ... We would send just the byte stream of the file
08:37:47 <anthony_> NM: I almost feel it's undefined to upload bytes without a type.
08:37:48 <anthony_> AR: I agree, as sever app must know what's getting.
08:37:50 <anthony_> NM: The file includes a Blob. There is clearly overlap there
08:37:52 <anthony_> HS: How do you get the media type reliably? From an implementation point of view
08:37:53 <anthony_> JS: We ask the OS. We give it a file and the OS looks it up.
08:37:55 <anthony_> CM: It's necessarily reliable but it's a common thing
08:37:57 <anthony_> AR: NM Said there is some redundancies in the interface
08:37:59 <anthony_> ... unless you invoke the slice method on the blob they may match.
08:38:01 <anthony_> ... but when you do the properties may vary.
08:38:03 <anthony_> CM: In the requirements we don't have a particular reason for chunk transferring. Can you give a use case for that?
08:38:06 <anthony_> AR: Yes.
08:38:08 <anthony_> ACTION: Arun to add the use case for chunk transfers.
08:38:08 <trackbot> Created ACTION-258 - Add the use case for chunk transfers. [on Arun Ranganathan - due 2008-10-27].
08:38:10 <anthony_> AB: We do both directions up and down.
08:38:12 <anthony_> AR: That's one thing not in this which is a file download of any sort.
08:38:15 <anthony_> ... so JS has a better use case for file downloads
08:38:16 <anthony_> 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
08:38:19 <anthony_> ... system I believe they upload it to the server and give back a URI
08:38:21 <anthony_> NM: So you are talking about use cases for upload and download?
08:38:23 <anthony_> JS: So this is for the use case where the user wants to download
08:38:25 <anthony_> NM: The webforms group has looked at this. I would prefer we leave this out and leave it to forms.
08:38:27 <anthony_> AR: So HTML5 has resolved to take on Webforms. This may be resolved in HTML5?
08:38:29 <anthony_> JS: My concern is I don't think it's very form related.
08:38:31 <anthony_> IH: Most data comes from contentEditable
08:38:33 <anthony_> JS: I think that if we are created a limited v1 spec that I think download can go into v2
08:38:35 <anthony_> AR: But it can be a use case/requirement
08:38:37 <anthony_> JS: If the forms people have looked at this maybe we should look at what they've done. If they have
08:38:39 <anthony_> ... a good solution we should reference that.
08:38:41 <anthony_> ACTION: Arun to add a use case for file download
08:38:41 <trackbot> Created ACTION-259 - Add a use case for file download [on Arun Ranganathan - due 2008-10-27].
08:38:43 <anthony_> CM: Is anyone desperate to have it v1 spec?
08:38:45 <anthony_> All: None
08:39:44 <jreyes> jreyes has joined #webapps
08:41:05 <anthony_> AR: I believe we can wrap up the discussion
08:41:33 <anthony_> ... by saying that unless a good technical argument is put forward by Apple
08:41:52 <timeless> timeless has joined #webapps
08:42:12 <anthony_> ... I think v1 should include a def of HTML5 file input element, blob as an async
08:42:21 <anthony_> ... I'm open to removing file dialog
08:42:46 <anthony_> ... If anyone has any objections regarding Google's blob API speak now
08:42:57 <anthony_> JS: Right now I'd like to see the sync functionality as async
08:43:36 <anthony_> CM: Summary, to have the whole thing as a blob API, have the whole thing as ASync, XHR extension and HTML5 input element
08:44:03 <anthony_> IH: I'm fine with having these features
08:44:08 <anthony_> ... I think we should make it simpler
08:44:19 <anthony_> AR: There is a method for removing files
08:44:28 <anthony_> ... can you give me a technical reason?
08:44:33 <anthony_> IH: To make it simpler
08:44:39 <anthony_> CM: What's the complication of removing a file?
08:44:56 <anthony_> IH: Unless we can absolutely defending having a feature
08:45:02 <anthony_> ... we should consider dropping it
08:45:10 <anthony_> AV: Seems like a better approach
08:45:14 <anthony_> AR: I can remove the remove
08:45:20 <anthony_> CM: Along with file download
08:45:27 <anthony_> ... Opera still wants to see file System
08:45:43 <anthony_> IH: That should also be separate spec like streaming
08:45:56 <anthony_> CM: Or be v2
08:46:07 <anthony_> DS: Should put future products in tracker
08:46:32 <anthony_> ACTION: Chaals to Provide a use case for file system access
08:46:32 <trackbot> Created ACTION-262 - Provide a use case for file system access [on Charles McCathieNevile - due 2008-10-27].
08:46:54 <anthony_> CM: With that I think we have enough to go forward
08:47:08 <anthony_> ... lets drop the proposal to publish the current draft
08:47:19 <anthony_> ... and you'll do up a new one which you'll propose for publishing
08:48:49 <chaals> scribeNick: sicking
08:49:35 <sicking> Topic: new work
08:51:05 <sicking> CM: current proposals are; stuff from NM, timer API from mjs, workers from whatwg, window API
08:51:42 <sicking> AR: with worker threads current proposal is to move it from whatwg to w3c to allow parties that prefer working with w3c can contribute
08:51:42 <dino> dino has joined #webapps
08:52:19 <sicking> HI: workers are part of w3c
08:52:28 <Hixie> http://dev.w3.org/html5/workers/Overview.html
08:52:41 <sicking> AR: propose to make it a formal work item
08:52:51 <sicking> CM: we need approval from AC
08:53:09 <sicking> CM: takes not long
08:53:28 <sicking> CM: need draft, editor
08:53:37 <sicking> CM: hixie, you wanna be editor?
08:53:43 <sicking> HI: roxxorz!
08:54:14 <arun> q+
08:54:34 <sicking> DS: the reason we need AC approval was that people was worried that webapps was taking on too much
08:54:43 <sicking> DS: we need usecase and requirements
08:54:45 <Hixie> s/roxxorz/I'm already editing the spec, so I don't mind changing the SotD to say "WebApps WG" instead of "HTMLWG"
08:55:11 <chaals> s/roxxorz/I'm already editing the spec, so I don't mind changing the SotD to say "WebApps WG" instead of "HTMLWG"/
08:55:43 <nrmehta> q-
08:56:14 <sicking> DS: how long will AC review take?
08:56:35 <sicking> AC: with this work item it should not take long. 3 weeks i believe
08:56:50 <sicking> DS: we can start work before AC approves
08:57:26 <sicking> CM: given that we have editor, anyone think we should not take it on?
08:58:02 <sicking> RESOLUTION: we will take it to the AC and ask permission to add to charter
08:58:25 <sicking> DS: we should ask the html wg for permission
08:58:53 <sicking> CW: as a chair i've said before that i think this is a good idea
08:59:26 <sicking> 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
09:00:00 <nrmehta> http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0104.html
09:00:05 <sicking> NM: i have proposal for seamless online/offline apps
09:00:48 <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 
09:01:15 <sicking> NM: objective is for applications to be able to access data when network is not available. There are a few use cases in draft
09:01:17 <arun> While WorkerThreads *may* move here as a result of request by Chairs, Content Security Policy still remains TBD (including within Mozilla)
09:01:39 <sicking> NM: main one is traveling sales guy to access data when not online
09:02:26 <sicking> NM: html5 proposes new data storage mechanism, such as localstorage or sql db
09:02:40 <anne> BITSY (with correct MIME type): http://html5.org/temp/2008/bitsy.xhtml
09:02:41 <sicking> NM: this proposal does not provide a new storage mechanism
09:03:06 <sicking> NM: you can use XHR to load and store data
09:04:06 <sicking> NM: you can also use hyper link, form submission, resource links (such as <link>)
09:04:55 <sicking> NM: caveat is that the data needs to be linked to an atom feed
09:05:37 <sicking> NM: intention is not to act as a replacement to html5 spec
09:05:52 <sicking> NM: it's mainly intended for resources, not data
09:05:55 <tlr> tlr has joined #webapps
09:06:30 <chaals> s/for resources, not data/for data, not resources (although it could be used for that)/
09:06:48 <sicking> NM: this proposal provides a way accessing data when offline, and for data to be submitted to server when going back online
09:07:38 <sicking> AR: does the builder object throw an error if a resource is not available and user is offline?
09:08:40 <sicking> NM: in such a case the resource will not be available
09:09:22 <sicking> AR: have you looked at rules for XHR with regards to access to headers
09:10:20 <sicking> NM: cookie header is allowed to be set in the builder object
09:10:27 <sicking> AR: are there cross site restrictions
09:10:44 <sicking> NM: We'd like to allow cross domain access, but we have not thought about that so far
09:11:15 <sicking> AV: can we back out from technical details and look at higher level
09:11:51 <chaals> q+
09:11:56 <sicking> NM: i'd like to able to look at existing objects when offline, and like to be able to change resources while offline
09:12:31 <sicking> NM: if a resource is not available at request time, request is stored and replayed when resource becomes available
09:13:23 <sicking> CM: at a very high level this uses atompub to define a synchronization mechanism
09:13:48 <CWilso> q+: to point out 1) IP 2) "sync is hard"
09:13:54 <sicking> CM: instead of having to implement your own synch mechanism yourself you use atompub and then let the browser do synchronization for you
09:14:01 <chaals> ack cha
09:14:11 <chaals> ack aru
09:14:29 <arun> q+
09:14:52 <sicking> NM: html5 has mechanism for storing data. Does not have ability to cache resources
09:15:02 <sicking> IH: html5 has offline cache
09:15:28 <sicking> CW: what is the status? It says copyright all rights reserved
09:15:52 <sicking> CW: sockets does allow this functionality. It's super powerful but also super hard
09:16:46 <sicking> CW: outlook guys have worked for 10 years to make offline exchange working. It works great now but it was really hard
09:17:08 <sicking> CM: w3c has process for submitting members only stuff
09:17:21 <sicking> CW: so is this a member submission?
09:18:08 <sicking> CW: if it says all rights reserved oracle our guys can't read it
09:18:17 <sicking> NM: oracle will not have problems making this public
09:18:58 <sicking> CW: please send it to the list and say that it's a member submission. That'll take care of the license
09:19:17 <dino> dino has joined #webapps
09:19:27 <chaals> ACTION: Nikunj to provide a legalese and process-friendly version of the proposal
09:19:27 <trackbot> Created ACTION-263 - Provide a legalese and process-friendly version of the proposal [on Nikunj Mehta - due 2008-10-27].
09:19:42 <sicking> JS: very fair, we gave microsoft the same crap when we got feedback under a license 
09:20:20 <chaals> q+ hixie
09:20:27 <chaals> ack cw
09:20:27 <Zakim> CWilso, you wanted to point out 1) IP 2) "sync is hard"
09:20:31 <sicking> NM: since sync is hard we should have functionality for it
09:20:54 <sicking> CW: we need to look at scenarios before going forward since we will get lots of questions
09:21:01 <arun> q--
09:21:07 <arun> q--
09:21:09 <sicking> CW: we should define use cases clearly
09:21:12 <arun> q-
09:21:29 <sicking> NM: we have not included indexing for example
09:21:42 <chaals> ack hi
09:22:58 <chaals> q+
09:23:21 <sicking> 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
09:23:56 <chaals> q+ to say that this appears to provide a solution for simple applications, supporting small-time developers, although not enough for really serious applications
09:24:25 <CWilso> q+ to say: XHR2 + localStorage + SQL storage + this + offline/cache control: whither?
09:24:50 <sicking> NM: we should have something for atompub. If 80% of atompub are solved by this then this is good enough for us
09:24:56 <chaals> ack ch
09:24:56 <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
09:25:05 <sicking> IH: this might be implementable using a JS library backed by XHR
09:25:33 <arun> +1 IH, modulo access to requests from within script
09:26:01 <sicking> NM: current specs does now allow syncing in background
09:26:11 <sicking> IH: workers might add that ability, though it scares me
09:26:27 <CWilso> CM: "idiots like me"
09:27:07 <sicking> CM: it appears to lower bar for developers to have this functionality
09:27:30 <arun> q+
09:27:32 <sicking> CM: if we decide to take this on, we need to look at what the html5 wg
09:27:36 <sicking> q+
09:30:12 <sicking> 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
09:30:53 <CWilso> ack cw
09:30:53 <Zakim> CWilso, you wanted to say: XHR2 + localStorage + SQL storage + this + offline/cache control: whither?
09:30:56 <chaals> ack cw
09:31:00 <sicking> NM: for example if the application updates data, there is no mechanism for making that data available to the app itself
09:32:22 <sicking> CW: it is likely that more advanced use cases we'll point to localstorage etc. It's important that we think of this at a continuum so that it integrates with other pieces
09:32:38 <paddy> paddy has joined #webapps
09:32:56 <chaals> s/we'll point to localstorage etc/will roll their own solution based on localstorage, XHR2, etc etc/
09:33:03 <sicking> CW: 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
09:33:34 <arve> arve has joined #webapps
09:33:39 <MikeSmith> RRSAgent, please make minutes
09:33:39 <RRSAgent> I have made the request to generate http://www.w3.org/2008/10/20-webapps-minutes.html MikeSmith
09:34:44 <sicking> DS: hixie, what is your opinion on splitting this up into a new WG
09:35:07 <paddy> paddy has left #webapps
09:35:18 <chaals> s/new WG/work item in this WG, with a stub in HTML/
09:36:15 <shepazu> q+
09:36:17 <sicking> IH: right now integration points are: navigating a browsing context, and when doing general network activity
09:36:41 <Hixie> ...which is defined just in the appcache step
09:37:14 <sicking> JS: there is also the markup for declaring manifests
09:37:45 <sicking> IH: so not the first thing i'd break out, but not the last either
09:37:46 <chaals> ack ar
09:37:53 <sicking> q-
09:39:11 <chaals> q+
09:39:49 <sicking> AR: if we were to consider this, we should check how much is already covered by existing spec. And we'd need use cases
09:40:09 <chaals> ack sh
09:40:51 <sicking> 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
09:41:16 <sicking> CW: i see mixed bag with having separate WG
09:41:53 <sicking> CW: i'd like a place where the discussion takes place where i can point people
09:41:58 <Hixie> q+
09:42:25 <sicking> CW: i wouldn't want to pull anything out from html5 since it's hard to pull too far apart
09:43:08 <chaals> s/anything/everything/
09:43:09 <sicking> DS: i can deal with the logistics
09:43:22 <chaals> ack ch
09:43:56 <sicking> CM: can i get more work to give to DS plez, kthnx
09:44:28 <sicking> CM: so he can not do it
09:44:39 <sicking> CM: simplest way to move forward is to keep in webapps group
09:44:49 <sicking> CM: needs to be coordinated with html wg
09:44:58 <sicking> CM: CW, can you follow discussion for webapps
09:46:14 <sicking> CW: having it in same list is a bit concerning due to traffic volumes
09:46:22 <sicking> JS: I'd like a separate list too
09:47:54 <CWilso> q?
09:47:56 <CWilso> ack hi
09:48:02 <sicking> CM: NM, are you prepared to do work
09:48:11 <sicking> s/work/work?/
09:48:15 <sicking> NM: yes
09:48:35 <chaals> s/work/the work/
09:50:38 <chaals> AvK: Want to see the things that can't be done with libraries
09:51:03 <nrmehta> q+
09:51:08 <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...
09:51:15 <chaals> ack nik
09:51:39 <chaals> JS: also concerned that we will get a 30% solution....
09:51:47 <chaals> s/will get/may get/
09:52:19 <sicking> 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
09:52:33 <sicking> IH: agree
09:52:36 <sicking> AV: agree
09:52:39 <sicking> JS: agree
09:54:48 <sicking> 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
09:55:28 <chaals> ACTION: Nikunj to provide more use cases and explanation of why we need something like bitsy
09:55:28 <trackbot> Created ACTION-264 - Provide more use cases and explanation of why we need something like bitsy [on Nikunj Mehta - due 2008-10-27].
09:56:08 <sicking> CM: do we want to talk about timers?
09:56:54 <sicking> AV: there are proposals to simply lower the minimum delay from 10ms to 4ms which might address use cases
09:57:29 <sicking> AV: however we might need to discuss moving setTimeout etc to this wg
09:57:33 <sicking> s/wg/WG/
09:57:38 <sicking> JS: who would be editor
09:57:58 <sicking> AV: opera has a proposed editor
09:58:15 <sicking> IH: i'd love to see it removed from the html5 spec
09:58:37 <sicking> CM: shall we resolve to shift spec to webapps
09:58:42 <arun> +1 AR
09:58:55 <sicking> IH: i support it as long as there is an editor
09:59:21 <arve> arve has joined #webapps
09:59:23 <sicking> RESOLUTION: will start process to get it added as work item for WG
10:00:04 <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]
10:00:16 <sicking> Topic: window object
10:01:44 <sicking> CM: we need an editor
10:01:51 <sicking> CM: it's really really really hard to edit
10:01:57 <sicking> CM: you must be insane to do so
10:02:02 <sicking> CM: anyone interested?
10:02:40 <sicking> IH: what is the advantage of having it as a separate spec
10:03:21 <sicking> IH: i used to think it's a good idea, but less sure at this point
10:03:55 <sicking> IH: I've tried to write the html5 spec such that svg can use it. By defining interactions for for example properties with same name
10:04:17 <sicking> CM: i'll talk with svg guys and see if anyone is prepared to do the work
10:05:07 <sicking> 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
10:05:28 <sicking> CM: anything more we should bring up?
10:06:01 <sicking> 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
10:06:10 <sicking> Topic: lunch
10:06:35 <sicking> will we have it, and will it taste yummy
10:11:59 <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
11:04:41 <Lachy> Lachy has joined #webapps
11:42:25 <nrmehta> nrmehta has joined #webapps
11:49:35 <arve> arve has joined #webapps
11:51:56 <Adam> Adam has joined #webapps
11:52:30 <wonsuk> wonsuk has joined #webapps
11:59:23 <wonsuk> wonsuk has joined #webapps
11:59:57 <Zakim> Zakim has left #webapps
12:00:28 <marcos> marcos has joined #webapps
12:00:53 <Adam> Adam has joined #webapps
12:01:33 <gsnedders> gsnedders has joined #webapps
12:06:07 <anthony_> anthony_ has joined #webapps
12:06:57 <DanC_lap> DanC_lap has joined #webapps
12:09:07 <DanC_lap> (found timbl's proposal http://lists.w3.org/Archives/Public/www-tag/2008May/0165.html )
12:09:10 <DanC_lap> hierarchical... check.
12:10:48 <DanC_lap> e.g. <imsg src="../over/there/in/the/zip/file" />
12:11:01 <DanC_lap> e.g. <img src="../over/there/in/the/zip/file" /> rather
12:12:04 <DanC_lap> expose... not sure.
12:12:15 <DanC_lap> outside... not sure
12:12:17 <DanC_lap> conflict... not sure
12:12:21 <hendry> hendry has joined #webapps
12:13:01 <MikeSmith> MikeSmith has joined #webapps
12:13:37 <hendry> is the widget stuff happening in group 1 or 2?
12:13:48 <Lachy> Lachy has joined #webapps
12:14:03 <hendry> and where is the back channel please
12:14:16 <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)
12:14:18 <Lachy> Lachy has joined #webapps
12:14:54 <adrianba> adrianba has joined #webapps
12:15:10 <DanC_lap> "no standard" applies to widget: too, right?
12:15:48 <DanC_lap> hendry, widget stuff is in A (dunno which is 1 vs 2)
12:17:23 <hendry> DanC_lap: wondered if i could drop in as an observer for an hour. can't see art online to clear it.
12:19:03 <DanC_lap> hendry, I just learned #wam is the channel for the widget stuff; ArtB is there
12:24:07 <hendry> DanC_lap: thanks!
12:24:46 <arve> arve has joined #webapps
12:27:37 <gsnedders> I guess I should return to the room
12:29:36 <CWilso> CWilso has joined #webapps
12:35:24 <anne> anne has joined #webapps
12:37:58 <tlr> tlr has joined #webapps
12:40:56 <sicking> sicking has joined #webapps
12:50:12 <adrianba> adrianba has joined #webapps
12:51:43 <nrmehta> nrmehta has joined #webapps
12:53:40 <arun> arun has joined #webapps
12:55:06 <Adam> Adam has joined #webapps
12:55:38 <Adam> scribeNick: Adam
12:56:01 <Adam> Topic: Element Traversal
12:56:03 <ed_fr> ed_fr has joined #webapps
12:56:12 <chaals> chaals has joined #webapps
12:56:44 <Lachy> just so this is recorded somewhere, even though it's not the topic yet, the remaining issues for selectors api are:
12:56:44 <Lachy> 1. Add last 40 emails to the disposition of comments
12:56:44 <Lachy> 2. deal with one issue regarding the feature string/
12:56:44 <Lachy> 3. Respond to other emails saying that the issues are postponed till v2.
12:57:37 <Adam> DS: you can skip over text nodes and just navigate the tree by the elements
12:57:51 <Adam> wrote some tests, has been CR
12:58:03 <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]
12:58:08 <Adam> DS: wrote some tests, has been CR
12:58:54 <Adam> DS: html 4, xhtml, etc versions of the files, tested in opera and batik which is an svg toolkit
12:59:08 <MoZ> MoZ has joined #webapps
12:59:16 <chaals> s/etc versions/svg versions/
12:59:17 <Adam> DS: each test passed by both opera and svg toolkit, 
12:59:32 <Adam> DS: would like to propose moving from CR to PR
12:59:43 <Adam> JS: sold
13:00:23 <Adam> JS: test cases do have some errors
13:00:45 <Adam> JS: etnamespace.svg test
13:01:02 <smaug> chaals: could you change loaded and total to unsigned long long?
13:01:38 <chaals> [smaug, I think I did that]
13:01:58 <Adam> AV: would like to see it test
13:01:59 <shepazu> http://dev.w3.org/2006/webapi/ElementTraversal/tests/
13:02:00 <smaug> "readonly attribute unsigned long   loaded;"
13:02:13 <sicking> http://dev.w3.org/2006/webapi/ElementTraversal/tests/et-namespace.svg
13:02:41 <chaals> [ah. found it... Better edited version coming soon]
13:02:47 <Adam> DS: were very basic test
13:03:02 <Adam> JS: are you testing dynamic stuff
13:03:04 <Adam> DS: no
13:03:34 <Adam> JS: will try to update his test, does some dynamic stuff
13:03:48 <Adam> JS: haven't tested any of the HTML test
13:04:31 <Adam> DS: should see the word pass if they pass
13:05:59 <Adam> AV: where is the function init test being called
13:06:08 <Adam> AV: doesn't seem to run the script at all?
13:07:39 <Adam> DS: thought other people wanted some things for version 2
13:08:31 <anne> ed_fr, I pointed out as much
13:08:40 <anne> ed_fr, the tests suck, for lack of a better word
13:08:45 <Adam> 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
13:09:29 <chaals> RESOLUTION: Subject to the identified bugs in tests being fixed, and implementations still passing, we will request PR status for Element Traversal
13:10:00 <Adam> AV: still think its not necessary to child element counts
13:10:07 <Adam> DS: likes it
13:10:22 <Hixie> is the next topic xhr?
13:10:23 <Adam> AV: whats wrong with children length
13:10:46 <Hixie> thanks
13:10:54 <anne> children.length is two characters shorter than childElementCount
13:10:55 <Adam> DS: it was svg to tiny user agent with mobile devices that don't already have node list interface
13:11:21 <Adam> DS: feedback from user agent vendors didn't want to do node list, that operation was significantly more costly to them
13:11:35 <Adam> DS: could be put in v2
13:11:48 <Adam> JS: totally bogus but not going to argue about it
13:11:53 <Adam> AV: agree it's bogus
13:12:52 <Adam> CM: if we stop talking about this we'll have more time to talk about v2
13:13:11 <Adam> JS: for the sake of moving on
13:14:10 <Adam> DS: moving on to v2
13:14:30 <chaals> ACTION: Doug to fix the tests for Element Traversal and make the implementation report
13:14:30 <trackbot> Sorry, amibiguous username (more than one match) - Doug
13:14:30 <trackbot> Try using a different identifier, such as family name or username (eg. dstamper, schepers)
13:14:40 <chaals> ACTION: schepers to fix the tests for Element Traversal and make the implementation report
13:14:40 <trackbot> Created ACTION-266 - Fix the tests for Element Traversal and make the implementation report [on Doug Schepers - due 2008-10-27].
13:15:15 <Adam> CM: do we need AC approval to do v2
13:15:29 <Adam> AV: seems unnecessary
13:15:53 <chaals> ACTION: schepers to check if we need approval to work on Element Traversal, and start working on v. 2
13:15:53 <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].
13:15:59 <Adam> AV: no need for an email to 400 people for people to say yes
13:16:03 <Adam> DS: doesn't agree
13:16:17 <Adam> DS: want to let them know we're doing work
13:18:34 <Adam> JS: thought wanted following children on text nodes
13:18:43 <Adam> JS: thougth somebody asked for that
13:19:22 <Adam> JS: point was should be in v2 and not in a separate space
13:19:23 <chaals> RESOLUTION: We want the new version with node lists etc...
13:19:37 <Adam> Topic: XHR
13:20:35 <shepazu> s/following children/next-previousElementSibling/
13:20:43 <Adam> AV: was comment made on last call, made some disposition of comments
13:20:50 <Adam> AV: need some kind of wg agreement
13:21:16 <Adam> AV: HS mentioned might be something in html5
13:21:33 <Adam> AV: actually doing the XHR actually integrate in to the event loop
13:21:44 <Adam> CM: why do we want to make this change
13:22:05 <Adam> HS: if you do a set timeout or trigger or an async event it defines in what order the events will fire
13:22:21 <Adam> AV: that is a part that has never been standardized but html5 does that
13:22:27 <Adam> AV: a few hours to do
13:22:47 <Adam> HS: net change spec will say fire task
13:23:31 <Adam> AV: that was the only to change in v1, v2 has other oustanding issues
13:23:56 <Adam> JS: at the risk of starting a war, what were the prospects of ie implementing the spec
13:24:45 <Adam> JS: feels the pain of it breaking stuff in IE
13:24:58 <Adam> JS: is there a strategy here to get everyone on the same page
13:25:59 <Adam> 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
13:26:17 <Adam> JS: what is the probabity of it eventually being implemented
13:26:21 <Adam> CW: it's not impossible
13:26:38 <Adam> JS: is there feedback from MS on things that should be changed in the spec
13:27:09 <Adam> ABate: does have a document that he has the action to review that but not sure what it has
13:27:50 <Adam> CM: seems like there are least some changes to spec so not going to do a last call today
13:28:18 <Adam> AV: don't have any open issues noted
13:28:54 <Adam> AV: some issue with char set that he doesn't have the detail down for yet
13:29:08 <Adam> JS: is afraid of changing the content type at all
13:29:21 <Adam> JS: why is that in the spec
13:29:29 <Adam> AV: somebody argued for it
13:29:39 <Adam> AV: so the server could figure out whats going on
13:29:39 <chaals> [ http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.23 available, with better editing (Thanks Smaug)]
13:30:04 <Adam> JS: personally wouldn't might waiting for that until XHR2 
13:30:20 <Adam> AV: doesn't want to add a dom attribute
13:30:26 <Adam> AV: to address it
13:30:48 <Adam> JS: alternative is to have a separate header
13:31:46 <smaug> [chaals: still "readonly attribute unsigned long   loaded;" ;) ] 
13:32:00 <smaug> [same for .total]
13:32:59 <Adam> AV: i really hate char sets
13:33:24 <Adam> AV: could leave it undefined, i don't like it, could say sending char set is a violation
13:33:46 <chaals> [d'oh. /me curses whitespace and fixes it AGAIN...]
13:34:00 <Adam> AV: could let MS and JS to go back for feedback review 
13:34:13 <Adam> Action: JS to review if char set is something that can be removed
13:34:13 <trackbot> Sorry, amibiguous username (more than one match) - JS
13:34:13 <trackbot> Try using a different identifier, such as family name or username (eg. jsoref, jsicking)
13:34:28 <nrmehta> This is a common problem with charsets on XML and HTTP http://www.xml.com/pub/a/2004/07/21/dive.html
13:34:30 <Adam> Action: jsicking to review if char set is something that can be removed
13:34:30 <trackbot> Created ACTION-268 - Review if char set is something that can be removed [on Jonas Sicking - due 2008-10-27].
13:35:41 <Adam> AV: did we want to go through comments for disposition
13:36:00 <Adam> HS: should go through the ones where the commentor is not happy with the response
13:36:21 <anne> http://dev.w3.org/2006/webapi/XMLHttpRequest/disposition-of-comments-2
13:36:57 <DanC_lap> [15:37] 	<trackbot>	ACTION-187 -- Dan Connolly to talk with TimBL about install-time names for widgets -- due 2008-10-27 -- OPEN
13:36:57 <DanC_lap> [15:37] 	<trackbot>	http://www.w3.org/2001/tag/group/track/actions/187
13:37:38 <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 ;) ]
13:37:52 <Adam> CM: don't have to look at all the dispositions from previous last call
13:38:12 <Adam> AV: #7 is rejected
13:38:28 <Adam> AV: several headers are being blocked on being sent
13:38:50 <smaug> [chaals: great, thanks. Will change long -> long long in mozilla]
13:38:53 <Adam> AV: he agrees with some being blocked but not others
13:39:30 <Adam> DS: have other people chimed in on that thread, is there some sort of 
13:39:49 <Adam> HS: can't allow the user agent is dodgy
13:39:52 <anne> http://lists.w3.org/Archives/Public/public-webapi/2008May/0408.html
13:40:50 <Adam> AV: some reason why referrer was on the block list
13:40:57 <Adam> JS: i don't think we block it yet do we
13:41:59 <Adam> DS: he is not an implementor
13:42:25 <Adam> DS: does anybody in the group disagree with AV
13:42:44 <Adam> DS: if the vendors are all ok then this is a polite disagree
13:43:26 <Adam> AV: was about the dependancy on html 5
13:44:29 <Adam> CM: lots of people said strip the reference to html5
13:44:47 <Adam> AV: they suggested to copy it all in, that was not the best way to go, would be huge
13:45:06 <Adam> DS: i requested the spec leave everything up to the host language
13:45:15 <Adam> AV: what is a host language?
13:45:29 <Adam> DS: if you're using a script it's the host language
13:45:49 <Adam> HS: bigger problem is you may not have a host language
13:46:00 <Adam> DS: that would be the host language
13:46:05 <MikeSmith> q?
13:46:08 <Adam> HS: then that would be the host language
13:46:38 <Zakim> Zakim has joined #webapps
13:46:46 <Adam> AV: some definitions could be inlined
13:46:55 <wonsuk> wonsuk has joined #webapps
13:47:32 <Adam> HS: there is a reference from html 5 to xhr in that part of the spec
13:48:44 <Adam> JS: can do cross domain at the browser chrome
13:48:57 <Adam> AV: could be a should do it
13:49:20 <Adam> JS: why do we need to specifiy that xhr is same origin
13:49:28 <Adam> AV: still need to define origin
13:50:29 <Adam> CM: would suggest that things that can be inlined are better off inlined
13:50:49 <Adam> CM: makes the case these things are massive complicated stuff makes the case easier to argue
13:51:13 <Adam> Action: chaals to look through the references to see what can reasonably inlined
13:51:13 <trackbot> Created ACTION-269 - Look through the references to see what can reasonably inlined [on Charles McCathieNevile - due 2008-10-27].
13:52:07 <Adam> AV: is ok with doing this
13:53:54 <Adam> AV: one issue with setting second arg to null
13:54:07 <Adam> JS: null handling is behavior is undefined
13:55:02 <kapyaho> kapyaho has joined #webapps
13:55:10 <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)
13:55:48 <Adam> JS: have 2 options, it gives special behavior for null, or do nothing
13:56:03 <Adam> AV: default is stringify to default
13:56:14 <Adam> JS: i think should leave it at the default
13:57:02 <nrmehta> q+
13:57:39 <Adam> HS: can't just leave it the default
13:58:45 <Adam> JS: a little afraid of doing any behavior even though it sounds somewhat reasonable to do
13:59:01 <Adam> CM: julian is the only one that wants to remove the header
13:59:22 <Adam> NM: value null is issue if you stringify it
13:59:34 <Adam> NM: there are no sementics defined for the value null
13:59:56 <Adam> NM: agree with JS
14:00:14 <chaals> Hixie, can't  recall off hand.
14:00:21 <Adam> HS: would much rather browser turn it in to empty string
14:01:43 <Adam> JS: would like it be explicitly undefined here
14:01:48 <Adam> AV: thats not possible
14:02:39 <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
14:02:49 <Adam> JS: things follow what web idl says to do
14:02:57 <Adam> AV: i don't think we should do that
14:03:40 <Hixie> sicking, http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/Overview.html?content-type=text/html;%20charset=utf-8
14:03:56 <Hixie> sicking: search for the third definition of "open(" in the IDL
14:04:08 <Hixie> and compare the second  and the third arguments
14:04:34 <Adam> NM: in opinion, thinks it's in violation of the spec
14:06:33 <Adam> CM: should we do what julian says and remove the header? in any case no, not goign to remove the headers
14:06:43 <Adam> Resoultion: not going to remove the header
14:06:53 <Adam> Resolution: not going to remove the header
14:07:06 <anthony__> anthony__ has joined #webapps
14:07:07 <karl> karl has joined #webapps
14:07:42 <karl> Hixie, chaals there is no formal requirement in the process document, but 
14:07:56 <Adam> taking a break
14:07:57 <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
14:08:30 <karl> there is
14:08:31 <karl>  Evidence that dependencies with other groups met (or not)
14:08:31 <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.
14:08:31 <karl>     * Is there evidence that additional dependencies related to implementation have been satisfied?
14:08:47 <Hixie> hm, interesting
14:08:55 <Hixie> so it's not a process issue?
14:09:49 <karl> not realy, it is more that if a document has a normative dependency on another one. it is risky.
14:09:58 <karl> the referenced document can change
14:10:08 <karl> changing then the conformance requirement. 
14:10:15 <karl> I guess it is case by case
14:10:28 <karl> and has to be strongly documented when going to the transition call.
14:10:47 <Hixie> very interesting
14:10:48 <Hixie> thanks!
14:10:53 <karl> your welcome
14:11:05 <karl> s/your/you're/
14:11:34 <tlr> tlr has joined #webapps
14:12:19 <wonsuk> wonsuk has left #webapps
14:13:20 <wonsuk> wonsuk has joined #webapps
14:18:15 <chaals> chaals has joined #webapps
14:19:21 <kapyaho_> kapyaho_ has joined #webapps
14:20:16 <aroben> aroben has joined #webapps
14:25:32 <MikeSmith> RRSAgent, make minutes
14:25:32 <RRSAgent> I have made the request to generate http://www.w3.org/2008/10/20-webapps-minutes.html MikeSmith
14:26:02 <CWilso> scribenick: cwilso
14:28:19 <shepazu> shepazu has joined #webapps
14:28:35 <gsnedders> gsnedders has joined #webapps
14:28:37 <kapyaho> kapyaho has joined #webapps
14:29:10 <CWilso> Topic: XHR still
14:30:50 <CWilso> JS: HTTP-only key issue.  thinks moz is going to block set-cookie header entirely.
14:31:41 <Hixie> http://dev.w3.org/2006/webapi/XMLHttpRequest/disposition-of-comments-2
14:32:11 <CWilso> AVK: you're suggesting not getting any value back for setcookie?  That would be cool...
14:32:29 <nrmehta> q+
14:32:50 <CWilso> JS: yes, we pretend like it's not there.  There's some concern about breakage, but seems unlikely.
14:35:30 <CWilso> IH: realm seems ok, since you can get it from the url.
14:35:39 <MoZ> MoZ has joined #webapps
14:36:21 <gsnedders> gsnedders has joined #webapps
14:36:52 <CWilso> 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?
14:37:03 <CWilso> JS: don't do that.  Or use Sec-.
14:39:32 <CWilso> AVK: Next issue: forms wg requested making instantiating an XHR object more abstract (e.g. don't need a Window object)
14:39:47 <CWilso> JS: XHR would make sense for Flash, but they don't have Window.
14:39:56 <CWilso> AVK: why do we care about Flash
14:40:00 <CWilso> ack NM
14:40:04 <CWilso> ack NR
14:40:25 <CWilso> JS: seems like we should make this possible
14:41:58 <arve> arve has joined #webapps
14:43:22 <CWilso> (discussion of proprietary platforms using XHR ensues)
14:46:09 <CWilso> IH: should just make the magic sentence non-normative
14:46:44 <maxf> maxf has joined #webapps
14:47:09 <CWilso> ACTION: Jonas Sicking to send email: Make non-normative suggestion that Window object can be omitted (for situations with no Window)
14:47:09 <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].
14:47:44 <CWilso> AVK: That's it for XHR1
14:48:49 <CWilso> 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?
14:49:06 <CWilso> AVK:  Yes.  I have tests for this and moz fails them.
14:49:46 <shepazu> Element Traversal implementation report: http://dev.w3.org/2006/webapi/ElementTraversal/tests/report/et-implementationReport.html
14:50:12 <CWilso> AVK: the events are fired synchronously.
14:50:21 <CWilso> [discussion ensues of whether this is true]
14:52:54 <CWilso> IH: why can't you skip events?
14:53:11 <CWilso> JS: because we put lots of other stuff in the event loop, including the UI
14:53:44 <CWilso> IH: from my point of view, that's a bug
14:53:52 <CWilso> JS: from my point of view, it's a feature.  :)
14:56:32 <CWilso> IH: we can (should?) change the spec to explicitly state that we keep pumping the event loop during sync XHR
14:58:06 <marcos> marcos has joined #webapps
15:01:01 <CWilso> AVK: will leave spec as is
15:01:40 <gsnedders> gsnedders has joined #webapps
15:02:43 <CWilso> AVK: that concludes addressing the comments
15:03:14 <CWilso> AVK: will update Disposition of comments.
15:05:00 <CWilso> Topic: Selectors api
15:05:01 <Lachy> http://dev.w3.org/2006/webapi/selectors-api/
15:05:45 <CWilso> LH: spec update is mostly done, almost ready to go to 2nd LC.  About 40 emails to go through for Disposition of Comments.
15:07:31 <CWilso> Last issue is the Feature string (hasFeature)
15:07:57 <CWilso> LH: rejected request to use XHTML syntax for example
15:09:45 <CWilso> LH: adding "scope" - moved to v2
15:13:16 <CWilso> LH: [number of issues relating to NSResolver, which was dropped]
15:13:59 <CWilso> MS: So three weeks or so for a new LC draft?
15:14:55 <CWilso> JS: defends namespaces
15:16:44 <CWilso> JS: I think we'll end up adding back NSResolver as it was
15:17:09 <CWilso> JS: but I'm fine with it not being in v1.
15:18:45 <CWilso> LH: need to fix up the list of acknowledgements.
15:19:19 <CWilso> AVK: proposes to publish LC again
15:19:41 <CWilso> hearing no object, MS says:
15:19:49 <CWilso> s/object/objections
15:20:08 <MikeSmith> RESOLUTION: Publish another LC WD for Selectors API, with plan to do 3-week LC period.
15:20:36 <CWilso> MS: tomorrow: AC, XHR2, Progress Events
15:23:20 <CWilso> IH: Window should contain browsing context and navigating context
15:24:11 <MikeSmith> i/Window should/Topic: Moving forward with Window Object spec?/
15:24:42 <CWilso> yeah, something like that.
15:25:52 <CWilso> MS: seems like we should be done for the day?
15:26:03 <CWilso> adjourned
15:26:06 <ArtB> ArtB has joined #webapps
15:26:08 <CWilso> RRSAgent, make minutes
15:26:08 <RRSAgent> I have made the request to generate http://www.w3.org/2008/10/20-webapps-minutes.html CWilso
15:27:48 <MikeSmith> back tomorrow at 9am
15:27:56 <gsnedders> <http://www.w3.org/2008/10/TPAC/Schedule.html> says groups at 8:30
15:28:00 <gsnedders> But I'd like breakfast.
15:28:12 <MikeSmith> thanks to everybody who scribed
15:35:24 <marcos> marcos has joined #webapps
15:38:43 <anthony> anthony has joined #webapps
15:54:42 <harry> harry has joined #webapps
16:12:09 <MoZ> MoZ has joined #webapps
16:13:32 <mjs> mjs has joined #webapps
16:38:46 <adrianba> adrianba has joined #webapps
17:04:01 <Zakim> Zakim has left #webapps
19:43:11 <DanC_lap> DanC_lap has joined #webapps
20:36:04 <DanC_lap> DanC_lap has joined #webapps
20:44:17 <anne> anne has joined #webapps
21:11:36 <arve> arve has joined #webapps
23:03:35 <heycam> heycam has joined #webapps
23:05:24 <nrmehta> nrmehta has joined #webapps