See also: IRC log
<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
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
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]
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
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
<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...
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
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.
<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
IH: Window should contain browsing context and navigating context
yeah, something like that.
MS: seems like we should be done for the day?
adjourned
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/roxxorz/I'm already editing the spec, so I don't mind changing the SotD to say "WebApps WG" instead of "HTMLWG"/ FAILED: s/roxxorz/I'm already editing the spec, so I don't mind changing the SotD to say "WebApps WG" instead of "HTMLWG"/ Succeeded: s/for resources, not data/for data, not resources (although it could be used for that)/ Succeeded: s/we'll point to localstorage etc/will roll their own solution based on localstorage, XHR2, etc etc/ Succeeded: s/new WG/work item in this WG, with a stub in HTML/ Succeeded: s/anything/everything/ Succeeded: s/work/work?/ Succeeded: s/work/the work/ Succeeded: s/will get/may get/ Succeeded: s/wg/WG/ Succeeded: s/etc versions/svg versions/ Succeeded: s/following children/next-previousElementSibling/ Succeeded: s/your/you're/ Succeeded: s/object/objections/ Succeeded: i/Window should/Topic: Moving forward with Window Object spec? Found ScribeNick: anthony Found ScribeNick: anthony_ Found ScribeNick: sicking Found ScribeNick: Adam Found ScribeNick: cwilso Inferring Scribes: anthony, anthony_, sicking, Adam, cwilso Scribes: anthony, anthony_, sicking, Adam, cwilso ScribeNicks: anthony, anthony_, sicking, Adam, cwilso WARNING: No "Present: ... " found! Possibly Present: AB ABat ABate AC AG AR AV AVK Adam All ArtB CB CM CW CWilso Carmelo DS DanC_lap EK HI HS Hixie IH JR JS Kangchan LH Lachy MS MikeSmith MoZ NM Resoultion WL adrianba anne anthony_ anthony__ aroben arun arve chaals dino dino_ ed_fr gsnedders hendry inserted joined jreyes kapyaho kapyaho_ karl kaz left marcos maxf nrmehta paddy scribenick shepazu sicking smaug timeless tlr trackbot webapps wonsuk You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Agenda: http://www.w3.org/2008/webapps/wiki/WebAppsMandelieuAgenda WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 20 Oct 2008 Guessing minutes URL: http://www.w3.org/2008/10/20-webapps-minutes.html People with action items: arun chaals doug jonas js jsicking nikunj schepers sicking[End of scribe.perl diagnostic output]