- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Wed, 03 Nov 2010 08:57:12 +0100
- To: public-webapps <public-webapps@w3.org>
The draft minutes from WebApps' November 2 meeting in Lyon are available
at the following and copied below:
http://www.w3.org/2010/11/02-webapps-minutes.html
WG Members - if you have any comments, corrections, etc., please send
them to the public-webapps mail list before November 10; otherwise these
minutes will be considered Approved.
-Art Barstow
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WebApps F2F Meeting
02 Nov 2010
See also: [2]IRC log
[2] http://www.w3.org/2010/11/02-webapps-irc
Attendees
Present
ArtB, DougS, MikeSmith, Geoffrey, SamW, Maciej, DaveR, Olli,
Adrian, EliotG, LaszloG, YaelA, AnssiK_SureshC, Dom, Johnson,
AnneVK, KlausB, Wonsuk_Lee, RichardT, BryanS, KaiH,
Bryan_Sullivan, Jonas, Pablo, Jeremy, Andrei, BoChen,
DavidRogers, EricU, AdamB, Anssi_Kostiainen
Regrets
Chair
ArtB
Scribe
Mike_Smith, MikeSmith, anne, jorlow
Contents
* [3]Topics
1. [4]DOM3 Events
2. [5]possible plans for console object spec/WG
3. [6]Audio XG
4. [7]XHR Testing
5. [8]XHR2 responseArrayBuffer
6. [9]Web DOM Core
7. [10]IndexedDB
8. [11]Keys
9. [12]internationalization
10. [13]Dynamic transactons:
11. [14]synchronous API
12. [15]Bugzilla
13. [16]quotas
14. [17]blobs
15. [18]Indexed DB Last Call
16. [19]File API
17. [20]FileSaver
* [21]Summary of Action Items
_________________________________________________________
<Barstow> ScribeNick: MikeSmith
<Barstow> Scribe: Mike_Smith
<Barstow> Date: 2 November 2010
<scribe> scribe: MikeSmith
DOM3 Events
<shepazu> [22]http://www.w3.org/2008/webapps/track/products/2
[22] http://www.w3.org/2008/webapps/track/products/2
<shepazu>
[23]http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Event
s.html
[23] http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html
shepazu: first is to our tracker page
… does not have every issue
… because CLOSED issues don't show up
… this reprepsents most of our LC technical comment
… we figured we might have to go through LC gain
… we will be adding the locale string
… as we discussed yesterday
… we will be making small changes
… improving wording
… editorial explanations
… going to LC again in Jan
… this time "for reals"
<scribe> … pending any upheavals
… doesn't specifcy evvery possible thing
… we had a comment from Garrett Smith
… also from Ample SDK
anne: Sergei Ilinsky
shepazu: wansts to modularize
… and Anne wants to modularize more too
shepazu: introduces all the things that were in DOM2 events
… plues text input, keyboard input, one mutation event
… though we have deprecated all the other mutation events
shepazu: I think we are more or less fr
… feature complete
anne: I'm the editor of DOM Core
… I think it make sense for DOM Core to define mutation events
anne: simiilar to how we define Form events inside the Forms spec
shepazu: we removed some Form-related events and those were moved to
the Forms spec
mjs: How about making mutation events die in a fire?
... I agree if they have really tight coupling to DOM behavior, it
makes sense to have them in the same place
… but tehre are some cases that don't require tight coupling at all
weinig: some of our chagnes are pending that they don7t break major
editing sites
… or goal is to turn it on and see what sites break
anne:
smaug_: I don't understand why were are moving mutation events
… I thought everybody just wanted them removed
mjs: I thikn the DOM events mechanism really has become part of the
core
smaug_: yeah, but some specs may refere DOM events, but don't need
to use DOM core
mjs: there is almost no way to use DOM events without also using DOM
core
anne: what is an example where it's that case that something relies
on DOM events but not DOM core
smaug_: some specs just extend [by adding new events and so don't
need to reference DOM core]
shepazu: anne, please explain what you want to move, specifically
<mjs> [24]http://www.w3.org/TR/DOM-Level-3-Events/#event-interfaces
[24] http://www.w3.org/TR/DOM-Level-3-Events/#event-interfaces
anne: there is a part call "Basic Event Interfaces"
… it would make sense to split that part out
shepazu: that is the core of DOM3 Events…
anne: in addition to that, I think the mutation events should move
too
mjs: smaug, I think your dependency argument doesn't work [because
the dependencies are complex]
anne: this is implementable in Java
<mjs> what I said about dependencies is that DOM3 Events has a
normative dependency on DOM 3 Core
<mjs> so there's no such thing as depending on DOM Events without
depending on DOM Core
Art: anybody else have comments?
adrianba: I don't have a strong opinion about where we go in the
long term
… there is plenty of time to talk about it
… right now there is an Event spec
… which is what we are targeting in IE9
… it seems like the wrong time now to start cutting up the problem
space in a different way
… let's move the spec forward as it is
adrianba: we are chartered to work in a new async spec for
[something like mutation events]
... stabilizing what we how now and moving forward seems like the
right thing
mjs: my preference would be to move forward but plan [to move things
to DOM Core later]
smaug_: I agree
… let's get DOM3 Events done now
… DOM Core will take years
adrianba: we have implemented some of the mutatation events
… we all understand the problems with mutation events
anne: I am afraid we are getting stuck with mutation events
adrianba: we are kind of stuck with them anyway
shepazu: if you are going to do part of it, it should all be in one
spec
anne: what do you mean by all?
... I don't think mouse events belongs together with it
shepazu: I would agree that we should move DOM3 Events forward as it
stands
anne: I don't think labeling them as deprecated helps us all that
much
mjs: if the number of implementations is increasing, then [clearly
it's not helping]
anne: making them async would be a big start
smaug_: we don't know that that will work
... tehre are some other approaches that are not event-based
... it is possible to remove some features from the platform
… it has been done
shepazu: deprecation is a warning to authors
... it's not helpful to remove them from the spec at this point
weinig: if they were removed from DOM3 Events, would MSFT consider
not adding them in IE9
[adrian shakes his head]
shepazu: they are only supporting some of them
adrianba: we are supporting them for interoperability reasons
shepazu: they are in the spec because implementors asked for them to
be in the spec
art: I noticed big list of issues
shepazu: a bunch of them are from David Flanagan
[book author
shepazu: Oli, Travis, Jacob Rossi, myself discussed them
… we have agreed already to accept most of the comments
… and have heard no objections from the list
shepazu: event.timestamp is one that we have still be discussing
art: can you do all 50 0f these by the end of the year?
shepazu: we can round-trip on these by end of January
... if nobody has more comments, let's move on
art: we don't have our next topic scheduled until 11am
possible plans for console object spec/WG
shepazu: a lot of people have said why don't specify the console
object
weinig: we just copied the console api into Webkit
mjs: there are a few things around console that are
Web-compatibility issues
... having to do with devs using console calls into their scripts
even after they have done debugging
weinig: there are a couple problems
... we don't think operations on the console should be visible to
Web pages
… we made some mistakes around that
mjs: the fact that console.log exists and doesn't have potentially
-> [25]http://getfirebug.com/wiki/index.php/Console_API Console API
[25] http://getfirebug.com/wiki/index.php/Console_API
adrianba: we having implemented the console in IE8-IE9
... there is a session tomorrow to discuss a new community-driven
spec-dev approah
… this might be a good case to use as a pilot
… for that approach
Audio XG
shepazu: about 6 months ago, we got in contact with some devs who
were working on an api from programatically writing and reading
audio streams
… and we started in Incubator Group
… XG
<Barstow> Audio XG Charter:
[26]http://www.w3.org/2010/04/audio/audio-incubator-charter.html
[26] http://www.w3.org/2010/04/audio/audio-incubator-charter.html
shepazu: and right now, Mozilla has a related API they have have
developed
… and Googl Chrome team has a related API as well
shepazu: and we have decided to start a new WG
<Barstow> Audio XG's mail list archive:
[27]http://lists.w3.org/Archives/Public/public-xg-audio/2010Oct/
[27] http://lists.w3.org/Archives/Public/public-xg-audio/2010Oct/
<Barstow> Mike: Chrome team is working on this API
<Barstow> ... think we want broader participation
shepazu: we would probably start the WG by February or so
Barstow: we will be back at 11am with anne at the podium
... XHR1 test suite, and XHR1 issues
[we take a 1 hour break:
<anne> [28]http://bitbucket.org/ms2ger/domparser
[28] http://bitbucket.org/ms2ger/domparser
<ArtB> ACTION: barstow ask Doug for a pointer to Google's "Before
Input Proposal" [recorded in
[29]http://www.w3.org/2010/11/02-webapps-minutes.html#action01]
<trackbot> Created ACTION-608 - Ask Doug for a pointer to Google's
"Before Input Proposal" [on Arthur Barstow - due 2010-11-09].
<ArtB> issue-119?
<trackbot> ISSUE-119 -- Consider adding input/keyboard locale to
text and keyboard events -- open
<trackbot> [30]http://www.w3.org/2008/webapps/track/issues/119
[30] http://www.w3.org/2008/webapps/track/issues/119
<Barstow> ScribeNick: timeless_mbp
<timeless> ScribeNick: timeless
XHR Testing
Scribe+ timeless
ArtB: Anne will be talking about XHR Level 1 Test Suite
<anne> [31]http://tc.labs.opera.com/apis/XMLHttpRequest/ and
[32]http://tc.labs.opera.com/svn/apis/XMLHttpRequest/
[31] http://tc.labs.opera.com/apis/XMLHttpRequest/
[32] http://tc.labs.opera.com/svn/apis/XMLHttpRequest/
… and Level 1 issues
anne: XHR Level 1 went to CR
… which means it's awaiting implementations
… of course XHR has been implemented long ago already
… there is a test suite which has been announced on the list
… but there has been little response
… Since people are here now, I guess I can ask people directly
sicking: I haven't looked at the testsuite yet, but is it fully
automated?
anne: you need a test harness, but it is automatic loaded a test
says PASS/FAIL
sicking: i think one of our desires is that things be as automated
as possible
anne: I agree
<anne>
[33]http://tc.labs.opera.com/apis/XMLHttpRequest/abort-during-done.h
tm
[33] http://tc.labs.opera.com/apis/XMLHttpRequest/abort-during-done.htm
… ? there is a testharness that it's written for which is used for
other testsuites from this group
[ anne describes how individual tests are structured ]
adrianba: how much has the test suite changed recently?
anne: the framework changed to make it the same as the HTML WG
… quite a few changed because a number weren't matching the spec
anymore
… the old testsuite was quite outdated
… some tests have been removed
… the number of tests has gone down. because some test assertions
were combined into single test
dom: did you follow any specific method to ensure every feature has
been tested?
anne: um, no
… i tried reading carefully to ensure everything is covered
artb: do you think anything is missing?
anne: there's an open item in the issue database about credentials
in urls
… the tests around that and authentication are not done yet
<dom> (should known bugs in the test suite be documented somewhere?)
<timeless_mbp> bryan: did you want to test posts?
<timeless_mbp> … for redirects (?)
<timeless_mbp> anne: i didn't want to because HTTP Biz is still
undecided on some of this
<timeless_mbp> … 301/302/307 ...
<timeless_mbp> sicking: another thing is that Mozilla + Opera
include dialogs on 307
<timeless_mbp> … it's sort of a requirement in the HTTP spec
<timeless_mbp> … but they don't have it for direct address
<timeless_mbp> … they're ratholes, so not tested yet, once they're
resolved they'll be tested
<timeless_mbp> anne: the only accessible methods are GET and POST
<timeless_mbp> sam: didn't hixie add DELETE?
<timeless_mbp> anne: we got him to remove it
<timeless_mbp> anne: Trailers aren't tested yet, because i didn't
know about them or how to test them
<timeless_mbp> sicking: so do we have to test them?
<timeless_mbp> anne: i might be able to test things w/ nph-
<timeless_mbp> … but i'm not sure what to expect
<timeless_mbp> sicking: trailers are after the response body
<timeless_mbp> anne: so i guess the text that talks about the
response body would have to talk about changing the state
<timeless_mbp> … as far as i'm concerned, we don't need to support
it
<timeless_mbp> … for readyState changes
<timeless_mbp> … but do you go to the done state
<timeless_mbp> sam: you said the php scripts are available in an svn
server?
<timeless_mbp> anne: yeah, it was the second link i posted
<dom>
[34]http://tc.labs.opera.com/svn/apis/XMLHttpRequest/resources/
[34] http://tc.labs.opera.com/svn/apis/XMLHttpRequest/resources/
<timeless_mbp> artb: i assume the action then is for everyone to
help this spec reach the exit criteria
<timeless_mbp> … is to review the tests
<timeless_mbp> anne: i assume there are some spec/test items which
need fixing
<timeless_mbp> … there's one other small test which might need
fixing
<timeless_mbp> … Björn Herman
<timeless_mbp> … pointed out byte order mark character
<shepazu> s/Byorn Herman/Björn Höhrmann/
<timeless_mbp> artb: we had set expectations that we wouldn't exit
CR before Feb 2011
<timeless_mbp> sicking: which is two conforming implementations?
<timeless_mbp> anne: I don't think that's likely to happen
<timeless_mbp> … I would encourage people to review the editor's
draft instead of this
<timeless_mbp> … because there have been some changes to make this
closer to XHR2
<timeless_mbp> … removing some throw conditions to enable CORS
<timeless_mbp> … those have been reflected in the testsuite already
<timeless_mbp> … i try to keep the testsuite and the draft in sync
<timeless_mbp> … that also means that if you implement to the
testsuite, there shouldn't be any conflicts with XHR2
<timeless_mbp> … if there are, that would be a bug
<timeless_mbp> anne: i'm not sure if we want to discuss any of the
issues now
<timeless_mbp> artb: that's up to you, we have some of the people in
the room
<timeless_mbp> anne: one of them is the user info protection in the
urls
<timeless_mbp> … i think microsoft doesn't implement it
<timeless_mbp> … and i think the other vendors do
<timeless_mbp> … so that you can have [35]http://user:pass@host/...
[35] http://user:pass@host/...
<timeless_mbp> anne: I think the HTTP people want to remove it
<timeless_mbp> sicking: I think we could try to remove it
<timeless_mbp> sicking: does the spec say they must be supported?
<timeless_mbp> anne: the http url spec does mention them
<timeless_mbp> anne: does the url get sent to the server?
<timeless_mbp> sicking: it might leak in the form of a referer
header
<shepazu> scribenick: timeless
sicking: i'm sure the url testsuite ...
anne: they are mentioned in the spec
… the spec has user and password arguments
… which are used to set authorization headers (?)
… if we don't remove it ...
anne: there is an issue in the bug database, i think it's the only
open issue at this point
<Zakim> shepazu, you wanted to describe policy on php in test suites
shepazu: so dom followed up with the Systems Team on PHP tests
… we just got confirmation that we will be hosting the php tests
<Barstow> ACTION: barstow XHR: add link to bugzilla in PubStatus
[recorded in
[36]http://www.w3.org/2010/11/02-webapps-minutes.html#action02]
<trackbot> Created ACTION-609 - XHR: add link to bugzilla in
PubStatus [on Arthur Barstow - due 2010-11-09].
… any tests that involves PHP will require review by the Systems
Team
… they will be hosted on the load balancing servers
anne: which servers?
dom: they'll be hosted on test.w3.org
... it would be helpful if you moved to the mercurial server
anne: i think there's a version there
… but probably not up to date
shepazu: the process will be such that you let us know when there's
a specific version you want deployed
… it will not be deployed until the systems team reviews it
shepazu: i think this will come up a lot
anne: there's also the web sockets stuff
dom: i think that is more complicated and will require more work
… i think we can manage, it requires more work
shepazu: for cross domain work, i think we'll need another domain
adrianba: we already have "test" and "test2" which are cnames
dom: if you are working on any test suite that has server side
things, please get in touch with the Systems Team early
anne: if you really want to test the really gritty networking stuff
… I think you will need HTTPS, certificates, DV, EV, OV,...
shepazu: those are good points
… Philippe is starting a new testing project
… so setting up a little test honey pot might be possible
dom: in general i think what's important is getting things to the
REC track, so get in touch with Systems Team earlier rather than
later
<scribe> ScribeNick: timeless
artb: anything else about XHR or its testsuite?
anne: no. apart from asking people to review/give comments
bryan: is it easy to set up?
anne: yes, there's a readme
<dom> (can we record an action to update the test suite on
dvcs.w3.org?)
artb: based on the feedback you've got so far on the XHR1 candidate
Action anne update the test suite on dvcs.w3.org
<trackbot> Created ACTION-610 - Update the test suite on dvcs.w3.org
[on Anne van Kesteren - due 2010-11-09].
anne: Before going back to last call
... make sure that we have two implementations that pass all the
tests
... and that the specification has all the implementations passed
that
... so that when we go back to LC we can go to PR after that
(skipping CR)
artb: the third bullet for this hour is a general discussion about
testing
... and we've already gone down that path quite a bit
anne: we could discuss responseArrayBuffer briefly
... i'm not sure we could reach a conclusion now
XHR2 responseArrayBuffer
sicking: I do have something to say on this
... So, the complicated issue is that...
... there's multiple topics
... the whole ongoing discussion right now about parsing...
... all requests into all response properties
... (Boris Z)
... what i'd like to do is move away from the current situation
... where we parse into multiple properties
... which is the XHR1 behavior
... I want to move to a way where you specify up front which thing
you want
adrianba: I think that makes sense
... so if you know it's coming as JSON or you want it as a Blob, you
can specify that
sicking: obviously we need to retain compatibility with XHR1
... and the stuff where you get a document
anne: this sounds kind of annoying
sicking: while it is nice to have things nice to have things parsed
into everything
... it's only nice if you don't have to consider all the resources
used
... what we're talking about is Document
anne: but you only need to create Document once it's requested
... you don't have to do it all up front
sicking: in our implementation
... we'll do charset-decoding differently depending on whether we're
parsing into a document or not
... so responseText changes depending on whether you have a document
... and the spec requires this
... everything else, JSON, Blobs, streams...
anne: streams?
sicking: we'll end up having to do it
adrianba: streams for media...
sicking: you can't set headers without this
adrianba: or you might want to process the data as it arrives
[anne was asking about using<video> ]
sam: we don't have to convince anne about streams
... more things will be using new content formats
geoffrey: there will be more and more kinds with time
anne: this screws with content negotation
[ scribe laughs ]
sicking: one of the aspects of my proposal is that you can set
.responseType after headers are received
... but before any data has been processed
anne: how would it work for sync requests/
sicking: we'd fire events
anne: but they're blocked by the sync request
sicking: you can't fire an async request, but you can fire a sync
event
... that's trivial implementation-wise
... you just run code on the main thread
anne: that sounds hairy
smaug: we explicitly want to get rid of ready state change events
... because that causes hanging in safari
adrianba: i think it's fine to not support sync requests for this
new feature
... because we want to push people toward async
jonas+sam: for workers sync requests are fine
anne: i'm saying you're opening a rathole
mjs: so what are we specifically talking about?
geoffrey: this was for when we receive content headers
anne: i don't think we should really fire events during a sync
request
... because conceptually that's confusing/seems really weird
mjs: there's generally a separate thread buffering the data from the
network
sam: the buffering is already happening
... anyone doing network handling on the main thread is probably
doing something really wrong anyway
sicking: i'm suggesting this *only* for workers
anne: I guess I would have to reference Workers from XHR2
sam: we kind of think of sync as deprecated in the main context now
... so adding features and having them exposed for the non workers
case is kind of like whatever
mjs: even in workers, i think it makes sense to encourage people to
have multiple concurrent requests
... by not providing this feature for sync
sicking: i'm not sure that this has taken off
artb: time check
... we have test suites we've already covered
... and you have ...
sicking: i posted my original proposal on content negotiation to the
list
... it's a long thread
... i had one more issue on byte array
... have you seen the proposal on the ecma list
... about another binary format?
anne: i'm not on the list
... i think it should align with webgl
<MikeSmith> sicking, url?
sicking: it's a long discussion
... i'll try to find the url
anne: i don't mind removing endianness
... but it would have to be aligned about webgl
sam: the reason for the endianness is that you want things in host
byte order for webgl
sicking: not all details are worked out yet
... the idea is to have it be fast
... but without exposing platform endianness
... the problem is that you're talking between two languages, JS and
GLSL
... david herman is the guy who made the proposal
<anne> GLSL = OpenGL Shading Language
<sicking>
[37]http://wiki.ecmascript.org/doku.php?id=strawman:binary_data
[37] http://wiki.ecmascript.org/doku.php?id=strawman:binary_data
<sicking>
[38]http://wiki.ecmascript.org/doku.php?id=strawman:binary_data_sema
ntics
[38] http://wiki.ecmascript.org/doku.php?id=strawman:binary_data_semantics
<sicking>
[39]http://wiki.ecmascript.org/doku.php?id=strawman:binary_data_disc
ussion
[39] http://wiki.ecmascript.org/doku.php?id=strawman:binary_data_discussion
artb: before we go on to DOM Core, I wanted to set aside a few
minutes for testing
<Guest724> anne , t'es fran�aise ?!
adrianba: we submitted tests for the webapps and html WGs
<adrianba>
[40]http://dvcs.w3.org/hg/webapps/file/5814514eeba4/tests/DOMEvents
[40] http://dvcs.w3.org/hg/webapps/file/5814514eeba4/tests/DOMEvents
adrianba: i'd like to move away from a system where we have a
different process per spec for submission
... we have some tests which we have committed to the mercurial
repository - i just pasted the link
... when I was talking to doug, he was trying to develop tests
alongside the spec
... we/he found that if you develop tests as you develop the spec,
it's easier to find spec issues
... there's a question of where to put tests as things are developed
... and keep aware of which things are agreed upon tests. which are
under development. which aren't agreed
sicking: we should try to require tests to be automatically runnable
<Barstow> ACTION: barstow work with Team and Chaals on formalizing
test suite process for WebApps [recorded in
[41]http://www.w3.org/2010/11/02-webapps-minutes.html#action03]
<trackbot> Created ACTION-611 - Work with Team and Chaals on
formalizing test suite process for WebApps [on Arthur Barstow - due
2010-11-09].
anne: ... whenever possible
adrianba: i think the work that anne did to refactor the XHR test
suite to use the same framework as the HTML tests
... he should receive credit for that, because it made things much
easier to review
sicking: when mozilla started adding tests to a framework
... it made things much better
... So if we have a formalized framework, and we should pick one,
and force everyone [in the webapps WG] to use that one
artb: for new tests...
shepazu: certainly most of the tests around browser stuff should use
the same framework
... there's probably some stuff in W3C outside of browser context
where this doesn't make sense
... the SVG group has also agreed to move to the same framework
... with SVG2, things are not going to go into the spec without
having tests added
... until we do that, we'll mark things as under review
... I guess i'm just offering a +1 for a common framework as much as
possible
... have we talked about testing with WebIDL?
... because if you describe stuff in a spec with webidl, you're
going to be able to extract that and do a certain amount of
automated tests
... or not?
sicking: i'm more of a fan of handwritten tests
... i'll believe it when i see it
dom: there was a perl tool that i mentioned on public-script-coord
...
... that generated tests from idl
... But I agree with jonas that it's better to start with manual
tests
adrianba: the model that creating things is that you can use
automatic creation to simplify basic generation of simpler tests to
supplement hand-written tests
sicking: at mozilla we're also looking into automatically testing
things that aren't automatically testable
... such as testing interacting with a file picker
... things which require apis which aren't web accessible
AnssiK: about functional testing... do you have things other than
unit testing?
sicking: what we do is that we expose a lot of stuff to javascript
... to have javascript override the dialog
... we can also fake real clicks on things
... it's being rewritten because the way we did it is not good
<dom> [42]perl tool to generate test cases based on WebIDL
[42] http://lists.w3.org/Archives/Public/public-script-coord/2009OctDec/0067.html
AnssiK: there's a thing called sellenium
[43]http://en.wikipedia.org/wiki/Selenium_(software) ]
[43] http://en.wikipedia.org/wiki/Selenium_(software)
scribe: which is cross browser
<AnssiK> s/sellenium/Selenium/
sicking: we're using a somewhat different approach
shepazu: when i tried to do test first / test in parallel
... i unfortunately failed
... i couldn't get the resources together in order to do that
<adam> Selenium can be automated using something like Hudson
[44]https://hudson.dev.java.net/
[44] https://hudson.dev.java.net/
shepazu: do people find testing in parallel to develop tests at the
same time as developing the spec
David: with WAC we made sure that there are Test Assertions as you
write the spec
<dom> [45]A Method for Writing Testable Conformance Requirements
[45] http://www.w3.org/TR/test-methodology/
David: the outcome of what you want can be written out as the spec
is written
... you have a test description file that links back to the spec
shepazu: is there interest in imposing this on the WG?
artb: yes, I took an action to work this out
... we'd put forward a proposal to the WG
... no one objected
adrianba: i volunteered testing resources
david: we strongly support any work in testing
<adrianba> s/i volunteered testing resources/i volunteer to help
define the process proposal/
david: we've had complaints in WAC, the other stuff has been quite
difficult for us to test (for lack of tests)
Web DOM Core
anne: DOM Level 3 Core was a REC a long time ago
... there's various differences in what web browsers implemented and
what the spec says
[ anne describes differences ]
<Barstow> ArtB: Web DOM Core abstract:
[46]http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#abstrac
t
[46] http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#abstract
anne: there are a few things HTML5 currently defines, which I think
should be moved back to DOM Core
... like what createElement does
<shepazu> [here's a short analysis of a case of WRONG_DOCUMENT_ERR:
[47]http://www.schepers.cc/svg/blendups/scriptbridge/scriptbridge-in
sertBug.html ]
[47] http://www.schepers.cc/svg/blendups/scriptbridge/scriptbridge-insertBug.html
anne: and defining what Document.charset/Document.defaultCharset/...
are.
... but leaving HTML to define when it sets them
... there's a more ambitious goal of getting rid of AttrNodes
[ sicking talks about DOM UserData]
sicking: i'm surprised no one has got requests for them
sam: we have
... but in the past we've said can't you use set property?
... and that's been good enough for them
sicking: but you could get conflicts with future specs
... yeah i'm all for getting rid of AttrNodes
... i was talking to travis from Microsoft about it
... we might need to add ownerElement on the Attr
... the main goal is to make them not be nodes
anne: this would move the namespaceURI away from Node
sicking: attribute nodes, i know we keep having security issues with
anne: the other things, it would be nice to get rid of, but it isn't
terribly important
... namespaceURI is only relevant for Element and Attr
sicking: it's useful for simple traversal
anne: the main reason is to avoid casting in Java
sicking: forms does the same thing, so you can iterate the
forms.elements array
... so you can avoid checking the type before getting properties
anne: but what would you be doing?
sicking: ...i don't know...
artb: so, this afternoon will be IndexDB, chaired by Anne
sicking: is anyone else planning to try to start removing these
things?
anne: we don't want to lead
sam: webkit would be interested in trying in nightlies
anne: we have already removed DOM UserData by not implementing it
sam: I have done the same for years, by not implementing it
anne: we are not actively removing things, but we have tried to
restrain ourselves from implementing things
... we would really like the Attr thing
sam: Are there any NodeLists that return Nodes other than Elements?
anne: there were. but I tried to kill those
... maybe there are no longer
Break for Lunch
<anne> arun, you there?
<anne> arun, you want to dial in for Indexed DB?
<MikeSmith> arun: you got a Skype ID?
<arun> Hi there Mike
<MikeSmith> hey man
<arun> MikeSmith: I'd like to dialin if possible.
<arun> anne: I'd like to dial in if possible.
<MikeSmith> scribe: MikeSmith
IndexedDB
<adam> Adam Boyet - Boeing
Paulo: there is a list of topics on the mailing list
<anne>
[48]http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/04
13.html
[48] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0413.html
<adrianba>
[49]http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/04
13.html
[49] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0413.html
s/Paulo/Pablo/
pablo: shall we do Keys?
... keys and tables… what we have today is simple keys
… compound keys, custom orders
<anne> Indexed DB:
[50]http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html
[50] http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html
…e.g., by date + by integer
… key value would be an array
sicking: not sure what syntax we should use
Keys
sicking: one proposal was array of "key paths"
jorlow: compound keys, being able to have arrays in your keys;
another thing is compound indexes
pablo: can't we reduce that to the same problem?
jorlow: one or part of the structure of the DB, one is something you
can do more ad hoc
… key could be array one time, a string or something else the next
<anne> who is +1.408.446.aabb? Nikunj?
<Nikunj> Nikunj
<anne> kk
<anne> screw you Zakim
pablo: rule of strictly sorting by type, then sort by value is very
sharp
jorlow: another question is, what do we want to do if you ahve a key
path to "foo" and you insert an item that doesn't include a "foo"
[discussion about what to do if a key path resolves to an array]
sicking: every place where we currently allow values we should also
allows arrays
[discussion about difficulty of implementing]
[sicking demonstrates with some code]
Option A is an array is just a single value
s/Option A/pablo: Option A/
jorlow: example is that people can have multiple names, and you can
construct an index such that multiple names map to the same person
pablo: I am not sure about composite keys made of arrays
sicking: the 2nd case is multiple records pointing to the same
object store
<Nikunj> I thought that composite key means there are many parts to
a key and that the parts are obtained from different paths
<Nikunj> The discussion seems to be about a single path resolving to
multiple values
sicking, see Nikunj comment
sicking: Nikunj, I agree with your interpretation
jorlow: yeah, agreed
... what are we going to do in teh case where you are inserting a
value that doesn't include something for a key path
e.g., you are inserting a person and you don't include a first name,
and the first name is the key
<Nikunj> Multiple keys in an index pointing to a single object is
not the same use case as compound key
jorlow: pablo, you seem to be worried that any handling of arrays is
going to be a lot of work
<Nikunj> The latter is about constructing a key serialization from
multiple keypaths
<Nikunj> The former changes the meaning of a key
<Nikunj> there is a difference between composite and compound keys
<Nikunj> See [51]http://en.wikipedia.org/wiki/Compound_key
[51] http://en.wikipedia.org/wiki/Compound_key
sicking: in solution A we can have a mix of values and arrays.
jorlow: should be allow keys to be indexes?
... the only use case is, search on multiple keys
... use case 1 is, my DB has people in it, with first name and last
name
… and I want to search for everybody who has both a certain first
name and a certain last name
jorlow: use case 2 is @@something @@
... 3rd possibility is first-name entry, last-name entry, then an
entry that has both that duplicates the first two
<jorlow>
[52]https://docs.google.com/document/edit?id=1IImAV3hzdqhaiaYfKzb-GW
lCgKUDQX3wiXPkqjFFFWg&hl=en&authkey=CIHTwIIM
[52] https://docs.google.com/document/edit?id=1IImAV3hzdqhaiaYfKzb-GWlCgKUDQX3wiXPkqjFFFWg&hl=en&authkey=CIHTwIIM
jorlow: choice is, do you want users to have to duplicate their
data? or do you want to have duplicated indexes
s/@@something @@/database contains people, find person with name
"foo", be that first or last name/
anne: so there's no AND ?
jorlow: there's no query language
Nikunj: I am not sure you need composite keys nor compound keys
jorlow: specifying a join language is a very big task
… for that, you can take whatever we've done so far here and
multiply it by 100
Nikunj: I am looking for a join _primitive_
internationalization
pablo: scenario is, you expect sort order to be in accord with your
language
<Nikunj> See
[53]http://www.w3.org/TR/2009/WD-WebSimpleDB-20090929/#entity-join
for a description of the join primitive
[53] http://www.w3.org/TR/2009/WD-WebSimpleDB-20090929/#entity-join
sicking: question is, are we happy with having a language on a
DB-wide basis? [as opposed to per object store]
<anne> [54]http://unicode.org/reports/tr10/
[54] http://unicode.org/reports/tr10/
Dynamic transactons:
jorlow: my vote is, don't do it
<Nikunj> What is the current topic?
<anne> Transactions
<anne> ... all transactions have time-consistency
<anne> ... how implementations achieve that is up to the
implementation
<anne> ... for writers you can only have one writer happening at the
time
<anne> ... unless they are separate object stores/tables
<anne> ... you could figure out the overlap and be very smart...
whatever (something like that)
<anne> ... should be some more non-normative text that explains this
<anne> JS: if you start two transactions; is there any guarantee
with respect to order?
<anne> JO: I don't think so; get weird behavior with locking; would
be shame as we get less concurrency
<anne> JS: what if there is overlap
<anne> JS: read, readrequest, write, writerequest
<anne> JO: no order guaranteed
<anne> JS: sounds very racy
<anne> JO: if you cared do not start them at the same time
<anne> Pablo: I don't think it is strictly a race
<anne> JO: what is the use for starting them at the same time?
<anne> Pablo: there should not be starvation
<anne> JS: already says that
<anne> JS: in Firefox there's no raceness and you always know the
order
<anne> JS: and no starvation either
<anne> JO: I can't think of any reason you start these and expect
them to run in the same order
<anne> thank you darobin
<anne> Pablo: workers also introduce these problems
synchronous API
<anne> within one worker you can only have one transaction
<anne> that assumes requiring locks is in order
<anne> make minutes
<mjs> ScribeNick weinig
<weinig> js: you already have to lock tables
<weinig> js: we have to make the transaction function take a
callback
<weinig> pablo: why can't we make the second transaction fail
<weinig> js: it would be very confusing for two independent
libraries to interact together
<weinig> pablo: that syntax seems very unwieldily
<weinig> jo: the function is just defining scope
<weinig> js: transactions within the function will throw
<weinig> jo: is anyone planning to implement sync
<weinig> jo: should we have a warning in the spec?
<weinig> jo: editors should try and keep sync and async in sync
<weinig> pablo: is everyone planning on doing async in main context
and sync and async in workers?
<weinig> everyone: yes
<Nikunj> can implementors provide an update on their implementation
status/plans
<weinig> pablo: should transactions be allowed in transactions?
<weinig> jo: maybe we should have an open nested transaction
<weinig> pablo: everything you would need to do you can do off the
transaction
<weinig> pablo: lets ignore the last few lines
<anne> scribe: anne
Bugzilla
RESOLUTION: not automatically assign to Nikunj; MikeSmith to follow
up
We have room number 4 all day tomorrow
times to be announced
<MikeSmith> if the problem is that Nikunj is not in the tracker DB I
can add him now
quotas
Pablo: by default we are not going to let apps fill the disk; so
what to do
<MikeSmith> trackbot, status?
Pablo: lots of degrees of freedom
MikeSmith, it would be nice if it was assigned to a nobody instead
since Nikunj is not the only editor
<MikeSmith> hai
<MikeSmith> I will change it now
Pablo: bytes are not necessarily meaningful as a unit
great
Pablo: first attempt to use the database; anything the app needs to
do?
SQL DB estimated size argument was very confusing
Dealing with size constraints:
1) no API impact
Chrome has a hard limit (with a non-specced error)
conclusion seems to be that some kind of quota error is needed
the spec does not say you create the index asynchronously
JO: i think it is implied
Pablo: it should be explicit
JO: i think it is in there, maybe should be more explained
... if it fails it fails the transaction
Does there need to be a way for asking for more space?
adrianba: in SilverLight we wanted to give the app more control
... if e.g. you download a huge file you do not want the UA to have
to ask and ask again
... but instead allocate once
JO: use cases are caching and some kind of permanent storage (i.e.
offline written email)
Pablo: impossible for us to decide
s/permanent/persistent/
JO: in Chrome we plan to group APIs together
... if you get 10 MB you can use it for several APIs
AvK: for the hint for the pre-allocation of memory case it should be
a generic API if we are heading in that direction
JO: for the persistant vs temporary case that should be noted on the
object store
... maybe change createObjectStore (or something like that) to take
this as parameter
blobs
adrianba: how long do blobs persist?
JS: tied to the Window object
Eric: if you want to change a Blob you create a new one
... you cannot create a File at the moment
... a file has a last modified time and a name
Pablo: I'm assuming when you store it in the DB it is a copy
JS: I hope Indexed DB to be enough
... not need a File System
... I don't want File System to have a capability that Indexed DB
does not
which is that you can modify a file that is stored
(if the scribe gets it correctly)
[questions on this topic are best asked on the list]
Indexed DB Last Call
JO: should we set goals
adrianba: address the existing issues
JO: full text search is important
... not gonna be efficient with what we have now
... full text search is extremely important to Google
<arun> Full text search was important to external developers as
well.
JO: I hope that one or two changes to the API can make this possible
... I want to get proof first, before adding something to the
specification
synchronizing...
Pablo: some kind of tracking
tombstones?
[further discussion on list]
arun, you still here?
<arun> anne, yep
cool
I guess Jonas can go through the File API mostly
might be tricky over the phone
<arun> anne, it's cool. I can hear you guys really clearly
<arun> anne, if I need to speak I'll just speak up.
<arun> anne, you can refer to the email I sent about agenda stuff if
you like.
[55]http://www.w3.org/2008/webapps/wiki/TPAC2010
[55] http://www.w3.org/2008/webapps/wiki/TPAC2010
[56]http://dev.w3.org/2006/webapi/FileAPI/
[56] http://dev.w3.org/2006/webapi/FileAPI/
File API
<arun> anne is the URL string trouble maker
<jorlow> scribe: jorlow
anne, doesn't like adding 2 more methods to window
arun, any other solution is back to the drawing board
anne, vendor prefixing might help limit usage
anne, but we still need to find the right solution
ericu, stuff put on the global object so that stuff is tied to the
lifetime of the window
jonas: when window is nagivated away, all urls are revoked
sam: you can do that regaurless of the syntax
ericu: what about if you pass from one window to another? this is
more explicit
sam, disagrees
jonas, is fine with other suggestions. thinks reusing url is weird
because it's only somewhat related
sam, so you could just have a blobURI object
jonas, an object might make sense....something about domURL
anne, don't you want to stringify it as well?
jonas, no
jonas, you'd create an object from a string
anne, you're still not solving the problem
jonas, trying to solve 2 problmes
jonas, something so we don't create strings...for that, need to
create a new type of interface...call it domURL for now
anne, domURL could be some union type of blob and stream
jonas, don't want create to be through some constructor and revoke
through a completely different api
jonas: we coudl create a global dummy object with both methods
arun: is it worth make global dummy object the same thing being
specced by adam barth
no
jonas: abarth's thing is to solve parsing urls. this isn't want we
need to do with blob urls
anne: not so sure
jonas: there's a vague resemblance given that they both revolve
around URLs
sam: agrees
... especially since adam's thing doens't exist yet
... can we discuss other things?
jonas: the proposed solution is some global object where we put 2
functions
anne: is there some existing place we could put them?
sam: maybe window.blob? but you want to do it for stream too so
maybe that's not a good place
ericu and others: k, let's move on
<timeless> s/coudl/could/
<timeless> s/doens't/doesn't/
sam: 2 questions. file list has been redefined to be a sequence of
files rather than a simple object. our implementation has file lists
like node lists. sequence doesn't have an item function.
anne: cameron said sequence isn't for that type of thing
jonas: saw hixie open a bug on something similar today
sam: in the mean time, should we go back to the simple interface?
anne: file lists should probably follow others
general agreement
sam: file reader + write have event handler attributes but don't
inherit from event target.
arun: it does
sam: sees it...what about writer?
ericu: if so, it's a bug
anne: we should have some consistency
sam: using implements probably makes sense (vs. inheriting) in the
spec
arun: agrees with sam
anne: XHR inherits
sam: in webkit, event target isn't in the prototype chain
... does it affect it though?
anne: maybe xhr should change
jonas: no advantage to not inheriting
sam: let's avoid multiple inheritance
jonas: agrees
... but most of these thigns don't inherit
anne: XHR does
jonas: but you can add it to the bottom of the chain
<timeless> s/thigns/things/
sam: everything in svg uses multiple inheritance
... we should probably bring this up as a WebIDL issue
jonas: it's unfortuate you can't add stuff to event target prototype
sam: if we could solve multiple inheritance in a good way, then
maybe it's a non-issue
... jonas, are you coming to tc39?
jonas: yes
anne: does it have anything more on file api?
s/does it/do we/
<MikeSmith> s/Transactions/scribe: anne/
jonas: request from google...when you request url, wants to do
something related to content type (didn't understand)
i didn't understand
<arun> arun: do we still have URL string dereferencing behavior?
ericu: right now content type is a property of blob
... we could add these properties to blob directly
arun: only contnet disposition was asked for
... just like content type
<MikeSmith> i/What is the current topic/scribe: anne
<timeless> s/contnet/content/
<MikeSmith> dunno
jonas: darin fisher has asked for content disposition. jonas has
said to use file save back to him
... and point the file saver to the blob directly
ericu: we want blob url to work just like any other
<arun> arun: right, so instead of Content-Disposition on Blob URLs,
you have a URL argument to the FileSave constructor.
ericu: gmail offline, for example, wants to be able to view and
download with similar code. just different urls. presentation layer
stays same, but backend just gives different urls
sam: not sure he understands why you'd create a url from a blob and
pass it to an XHR
jonas: not sure anyone suggested this
sam: isn't that the reason to set headers: to get it through XHR?
jonas: no, it was just to explain
... iframes care about headers
... to do gmail file saving, create iframe, take blob, create url,
content dis. header, iframe looks at that header, it works
ericu: can't you do that today?
... only need iframe trick if you don't have content disposition
header
... wait...hm...
jonas: link with target: _blank
sam: that opens a window
anne: behavior varries
sam: agreed
... very marginal use case
jonas: it's a very roundabout way of triggering file save dialog
<arun> arun: +1 to sam, sicking
ericu: urls have these properties already
... making offline urls work just like online urls seems nice
sam: they're more a property of the resource, not the url itself
jonas: it's actually a property of the person initiating the load
... make file save support taking url
... same architecture for blobs and urls
sam: some browsers default behavior is not prompt and download to
directory
... so that'd behave differently
... iframe with content disposition treated as download, file saver
treated as save as
jonas: i'm not sure we'd behave differently
timeless: we shipped that behavior 2+ years ago
<timeless> [we = Mozilla/Firefox]
ericu: if you want file saver to do the default, that's another
behavior
jonas: if people only want a download mechanism, we should do it
right not extend hack
arun: hack exists for http reasons
... ericu's "uber question" is a good one
ericu: allowing all headers in seems cleaner
anne: it's complicated if we only care about content disposition
sam: setting something like x frame options could be useful
... my recollection are that most of these things are attributed to
the resource not the url
... it seems a bit hackish to set headers on a blob
ericu: agrees. a blob might never be used as a url
... in some cases, the headers are more assicated with the url
rather than the resource itself
jonas: this discussion has gotten a bit meta
... should the headers arguments exist on the blob or create url
function
sam: that's one question. the other is whether we need the headers
ericu: likes headers. if we have them, put them on createURL
function
anne: let's move discussion to list
... talks about his sneaky plan
ericu: we can go back to file after writer/system questions
<timeless> the example for using URL instead of Blob to have the
bits is to match Gmail where an image attachment has View and
Download links - two urls to the same blob data
ericu: doesn't have any issues to bring up
anne: can you give a quick introduction?
ericu: does said introcution...
<timeless> s/cut/duct/
FileSaver
<anne> s/FileSaver/File: Writer and File: Systems and Directories/
sam: so file writer sync doesn't not pop up a dialog?
<timeless> s/introcution/introduction/
ericu: yup
... this is just a writing interface...doesn't describe how to get
access
... file system spec gives another away to get access to a file
... otherwise the only way is file saver
... file system is like a chrooted environment to create dirs,
files, etc
... file system is good if your data isn't structured
... game designers want this for art assets, for example
sam: what about indexedb
jorlow: or app cache
ericu: not good match for app cache...it's all or nothing
jonas: thinks system is not needed
... because of indexedDB
sam: data cache or an extension to app cache might have worked as
well
ericu: yes
sam: waht about various databases
<timeless> s/waht/what/
sam: jonas's face was scary
ericu: it's a matter of taste
sam: seems like adding this much API surface area for a matter of
taste is bad taste
ericu: it's more than just taste
<arun> arun: I agree with ericu about it being a matter of taste.
Some like file system based metaphors, and some like databases for
everything.
ericu: sharing data with apps outside of the browser is good too
sam: indexedDB could store files in the file system if it wanted to
ericu: that seems odd. no hierarchy
jonas: yeah, no meta data
ericu: gives a use case
sam: if that's a use case, it should be explicit in spec
... and what about when file system doesn't exist
ericu: that's one reason to make it explicit in the spec
... it's a significant motivator, but not required
jorlow: you could store meta data ad-hoc in indexedDB if you wanted
to
jonas: the meta data will be understandable by other apps
... hurdle: some people are nervous about allowing websites to save
stuff to a known location
sam: we probably want to add changes to mac os X to allow ..?
ericu: in current implementation, files not saved in known location
... describes the hack
... many apps know how to scan a hierarchy of dirs (that can scan it
in)
timeless: then you just exploit some app like iTunes or picassa
adrianba: what about social engineering
ericu: opening a file deep in the chrome profile dir...?
... and your av software should still run on it
adrianba: they have support for knowing the source of the download
<timeless> s/picassa/Picasa/
sam: mac os x too
jorlow: can't the file system api just set the bits
<timeless> windows too
adrianba: we distinguish between url and site
ericu: this makes it slightly harder, but it's not a fundamental
issue
adrianba: allowing a web application to save something without
immediate consent of user...then social engineering
<timeless> [ such as attacking Sherlock, Google Desktop Search ]
ericu: it's a valid concern and i understand. you might just need to
tweak the reputation system a bit to handle this case
sam: my issue is not security, it's that we already have a lot of
storage options
... unnecessary risk to throw 2 new APIs at the web at once
<arun> OK big +1 to weinig
ericu: well it's not there yet and it won't necessarily be popular
sam: but it can never be removed
jorlow: isn't it behind prefix
timeless: that doens't matter much
ericu: and actually our implementation is not behind prefix
... which is a fair objection
... a number of devs asked for it
sam: web sql is same
<timeless> s/doens't/doesn't/
sam: we should have been more careful and not do it
... has actual question
... file saver sync doesn't seem to have an actual interface
attached to it?
ericu: will fix it
sam: from worker, would you pop up save dialog
... what window would it be attached to
ericu: shared worker is an odd case
jorlow: brought up more shared worker issues similar
ericu: yeah...we need to fix some stuff
jonas: want file save to be able to handle the url
... content disposition is a hack, so it'd be nice to move away from
it
<arun> Yeah; while we hash out headers on Blob URIs, I think it's
good to allow FileSaver to have a URL argument
sam: people already hack around it, iframe trick might as well
become official
... anne are you editing progress events?
... is there going to be some way to say some interface implements
something...rather than repeating the work for each progress event
jonas: there's some web idl way to say supplemental, but reverse
ericu: onload start, and that doesn't make sense when you're writing
<anne> [57]http://www.w3.org/TR/progress-events/
[57] http://www.w3.org/TR/progress-events/
jonas: interesting situation when you want progress events for
something other than loads since much of them have load in the name
anne: they're actually specced to be pretty vague
... can't rename them at this point
adrianba: could you have multiple names for something
sam: this is a bad idea because events are expensive, therefore
firing 2 events is expensive
... we've done this for focus and DOM (yell) Focus
mjs: you can't actually alias because of add event listener's
semantics
jonas: agreed, aliasing is bad
anne: the event names are just suggestions
... you can call your events whatever you want
jonas: it makes sense to do things this way
sam: should they be save start?
ericu: filewriter derives from this and uses the same events
jonas: the interface names are fully generic
anne: interface still has loaded
ericu: I think I just put done?
... going to fix the spec
mjs: we should change the syntax of html
<mjs> </sarcasm>
ericu: taking a step back....
sam: when people implement event listeners, the event they get will
be a little funny because it has words like loaded
anne: inherited progress events from svg...no one backed me up
mjs: lots of bike shedding
jonas: it sucks to add aliases
sam: maybe add progress of loaded that calls the same underlying
function
... bytes progressed maybe?
jonas: just use progress
anne: we do have some aliased properties elsewhere I guess
... let's leave "early"
anne's chairing skillz are celebrated
Summary of Action Items
[NEW] ACTION: barstow ask Doug for a pointer to Google's "Before
Input Proposal" [recorded in
[58]http://www.w3.org/2010/11/02-webapps-minutes.html#action01]
[NEW] ACTION: barstow work with Team and Chaals on formalizing test
suite process for WebApps [recorded in
[59]http://www.w3.org/2010/11/02-webapps-minutes.html#action03]
[NEW] ACTION: barstow XHR: add link to bugzilla in PubStatus
[recorded in
[60]http://www.w3.org/2010/11/02-webapps-minutes.html#action02]
[End of minutes]
Received on Wednesday, 3 November 2010 07:57:54 UTC