Re: [IndexedDB] Spec changes for international language support
Hi Pablo, I will reassign this bug to Eliott. Nikunj On Feb 17, 2011, at 6:38 PM, Pablo Castro wrote: > btw - the bug is assigned to Nikunj right now but I think that's just because > of an editing glitch. Nikunj please let me know if you were working on it, > otherwise I'll just submit the changes once I hear some feedback from this > group.
[IndexedDB] Spec changes for international language support
We discussed international language support last time at the TPAC and I said I'd propose spec text for it. Please find the patch below, the changes mirror exactly the proposal described in the bug we have for tracking this: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9903 btw - the bug is assigned to Nikunj right now but I think that's just because of an editing glitch. Nikunj please let me know if you were working on it, otherwise I'll just submit the changes once I hear some feedback from this group. Thanks -pablo Left file: \IndexedDB Specs\20110217\Speclet_023_IDB_API_Asynchronous_APIs.original.html Right file: \IndexedDB Specs\20110217\Speclet_023_IDB_API_Asynchronous_APIs.html copy 6 add 7 readonly attribute DOMString language On getting, this attribute MUST return the language that is configured in this database for string collation. If no collation has been configured for a database this value is null and the database will use binary collation. copy 6 copy 6 add 24 IDBRequest setLanguage() This method changes the language used by the database for string collation. Note that this method must only be called from a VERSION_CHANGE transaction callback. Changing the language in a database that already contains data typically involves reading and re-writing the entire database and thus can be a time consuming operation. optional DOMString language The language to be used in the database specified as a language identifier as described in [[!BCP47]]. NOT_ALLOWED_ERR This method was not called from a VERSION_CHANGE transaction callback. DATA_ERR The language parameter contained a string that was not a valid language identifier or was a language identifier not supported by the system. copy 6 Left file: \IndexedDB Specs\20110217\Speclet_022_IDB_API_Synchronous_APIs.original.html Right file: \IndexedDB Specs\20110217\Speclet_022_IDB_API_Synchronous_APIs.html copy 6 add 7 readonly attribute DOMString language On getting, this attribute MUST return the language that is configured in this database for string collation. If no collation has been configured for a database this value is null and the database will use binary collation. copy 6 copy 6 add 24 void setLanguage() This method changes the language used by the database for string collation. Note that this method must only be called from a VERSION_CHANGE transaction callback. Changing the language in a database that already contains data typically involves reading and re-writing the entire database and thus can be a time consuming operation. optional DOMString language The language to be used in the database specified as a language identifier as described in [[!BCP47]]. NOT_ALLOWED_ERR This method was not called from a VERSION_CHANGE transaction callback. DATA_ERR The language parameter contained a string that was not a valid language identifier or was a language identifier not supported by the system. copy 6 Left file: \IndexedDB Specs\20110217\Speclet_020_IDB_API_Constructs.original.html Right file: \IndexedDB Specs\20110217\Speclet_020_IDB_API_Constructs.html copy 6 add 4 Every database also has a language that indicates the language that should be used for collating strings when comparing keys. copy 6 copy 6 delete 1 add 2 value with no need to separate them by type. When comparing a DOMString with another DOMString, the database language should be used to determine the specific collation rules to be used. copy 6
Re: [IndexedDB] More questions about IDBRequests always firing (WAS: Reason for aborting transactions)
On Thu, Feb 17, 2011 at 3:58 PM, Pablo Castro wrote: > > From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] > On Behalf Of Jeremy Orlow > Sent: Thursday, February 17, 2011 11:51 AM > > >> On Thu, Feb 17, 2011 at 11:12 AM, Jonas Sicking > wrote: > >> On Thu, Feb 17, 2011 at 11:02 AM, ben turner > wrote: > >> >>> Also, what should we do when you enqueue a setVersion transaction > and then > >> >>> close the database handle? Maybe an ABORT_ERR there too? > >> >> > >> >> Yeah, that'd make sense to me. Just like if you enque any other > >> >> transaction and then close the db handle. > >> > > >> > We don't abort transactions that are already in progress when you call > >> > db.close()... We just set a flag and prevent further transactions from > >> > being created. > >> Doh! Of course. > >> > >> If the setVersion transaction has started then we should definitely > >> allow it finish, just like all other transactions. I don't have a > >> strong opinion on if we should let the setVersion transaction start if > >> it hasn't yet. Seems most consistent to let it, but if there's a > >> strong reason not to I could be convinced. > >> > >> What if you have two database connections open and both do a setVersion > transaction and one calls .close (to yield to the other)? Neither can start > until one or the other actually is closed. If a database is closed (not > just close pending) then I think we need to abort any blocked setVersion > calls. If one is already running, it should certainly be allowed to finish > before we close the database. > > This sounds reasonable to me (special case and abort the transaction only > for blocked setVersion transactions). We should capture it explicitly on the > spec, it's the kind of little detail that's easy to forget. > Captured in http://www.w3.org/Bugs/Public/show_bug.cgi?id=12114
[Bug 12114] New: Blocked setVersion transactions should be aborted when their database is closed
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12114 Summary: Blocked setVersion transactions should be aborted when their database is closed Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: dave.n...@w3.org ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org On Thu, Feb 17, 2011 at 3:58 PM, Pablo Castro wrote: >> What if you have two database connections open and both do a setVersion >> transaction and one calls .close (to yield to the other)? Neither can start >> until one or the other actually is closed. If a database is closed (not >> just close pending) then I think we need to abort any blocked setVersion >> calls. If one is already running, it should certainly be allowed to finish >> before we close the database. This sounds reasonable to me (special case and abort the transaction only for blocked setVersion transactions). We should capture it explicitly on the spec, it's the kind of little detail that's easy to forget. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
RE: [IndexedDB] More questions about IDBRequests always firing (WAS: Reason for aborting transactions)
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Jeremy Orlow Sent: Thursday, February 17, 2011 11:51 AM >> On Thu, Feb 17, 2011 at 11:12 AM, Jonas Sicking wrote: >> On Thu, Feb 17, 2011 at 11:02 AM, ben turner wrote: >> >>> Also, what should we do when you enqueue a setVersion transaction and >> >>> then >> >>> close the database handle? Maybe an ABORT_ERR there too? >> >> >> >> Yeah, that'd make sense to me. Just like if you enque any other >> >> transaction and then close the db handle. >> > >> > We don't abort transactions that are already in progress when you call >> > db.close()... We just set a flag and prevent further transactions from >> > being created. >> Doh! Of course. >> >> If the setVersion transaction has started then we should definitely >> allow it finish, just like all other transactions. I don't have a >> strong opinion on if we should let the setVersion transaction start if >> it hasn't yet. Seems most consistent to let it, but if there's a >> strong reason not to I could be convinced. >> >> What if you have two database connections open and both do a setVersion >> transaction and one calls .close (to yield to the other)? Neither can start >> until one or the other actually is closed. If a database is closed (not >> just close pending) then I think we need to abort any blocked setVersion >> calls. If one is already running, it should certainly be allowed to finish >> before we close the database. This sounds reasonable to me (special case and abort the transaction only for blocked setVersion transactions). We should capture it explicitly on the spec, it's the kind of little detail that's easy to forget. -pc
Re: [IndexedDB] More questions about IDBRequests always firing (WAS: Reason for aborting transactions)
On Thu, Feb 17, 2011 at 11:12 AM, Jonas Sicking wrote: > On Thu, Feb 17, 2011 at 11:02 AM, ben turner > wrote: > >>> Also, what should we do when you enqueue a setVersion transaction and > then > >>> close the database handle? Maybe an ABORT_ERR there too? > >> > >> Yeah, that'd make sense to me. Just like if you enque any other > >> transaction and then close the db handle. > > > > We don't abort transactions that are already in progress when you call > > db.close()... We just set a flag and prevent further transactions from > > being created. > > Doh! Of course. > > If the setVersion transaction has started then we should definitely > allow it finish, just like all other transactions. I don't have a > strong opinion on if we should let the setVersion transaction start if > it hasn't yet. Seems most consistent to let it, but if there's a > strong reason not to I could be convinced. > What if you have two database connections open and both do a setVersion transaction and one calls .close (to yield to the other)? Neither can start until one or the other actually is closed. If a database is closed (not just close pending) then I think we need to abort any blocked setVersion calls. If one is already running, it should certainly be allowed to finish before we close the database. J
Re: [FileAPI] readAsDataURL()
On 2/17/11 2:00 PM, Jonas Sicking wrote: I think data-urls are allowed to have no content-type. Just like http requests can return no content-type header. A difference is that if HTTP returns no content-type header then the type is sniffed, whereas a data: URI with no media-type is treated as text/plain. This is specified in RFC 2397 and implemented at least in Opera, Gecko, Safari, and Chrome. -Boris
Re: [IndexedDB] More questions about IDBRequests always firing (WAS: Reason for aborting transactions)
On Thu, Feb 17, 2011 at 11:02 AM, ben turner wrote: >>> Also, what should we do when you enqueue a setVersion transaction and then >>> close the database handle? Maybe an ABORT_ERR there too? >> >> Yeah, that'd make sense to me. Just like if you enque any other >> transaction and then close the db handle. > > We don't abort transactions that are already in progress when you call > db.close()... We just set a flag and prevent further transactions from > being created. Doh! Of course. If the setVersion transaction has started then we should definitely allow it finish, just like all other transactions. I don't have a strong opinion on if we should let the setVersion transaction start if it hasn't yet. Seems most consistent to let it, but if there's a strong reason not to I could be convinced. / Jonas
Re: [IndexedDB] More questions about IDBRequests always firing (WAS: Reason for aborting transactions)
>> Also, what should we do when you enqueue a setVersion transaction and then >> close the database handle? Maybe an ABORT_ERR there too? > > Yeah, that'd make sense to me. Just like if you enque any other > transaction and then close the db handle. We don't abort transactions that are already in progress when you call db.close()... We just set a flag and prevent further transactions from being created. -Ben
Re: [FileAPI] readAsDataURL()
On Thu, Feb 17, 2011 at 9:46 AM, Arun Ranganathan wrote: > David, > >> >> Arun, >> >> I'm assuming that you mean for the resulting data:// URL to have a >> mime >> type in it, right? But the spec just says to take the "blob's data >> content" and doesn't say anything about using the type of the blob >> when >> creating the URL. > > Yes, you're absolutely right, I understand you now! The steps should specify > use of the type property on Blobs. In fact, sometimes the type may not be > available on Blobs. In this case the specification should go to the error > steps, since a valid data: URL cannot be generated. I think data-urls are allowed to have no content-type. Just like http requests can return no content-type header. / Jonas
Re: [FileAPI] readAsDataURL()
David, > > Arun, > > I'm assuming that you mean for the resulting data:// URL to have a > mime > type in it, right? But the spec just says to take the "blob's data > content" and doesn't say anything about using the type of the blob > when > creating the URL. Yes, you're absolutely right, I understand you now! The steps should specify use of the type property on Blobs. In fact, sometimes the type may not be available on Blobs. In this case the specification should go to the error steps, since a valid data: URL cannot be generated. -- A*
Re: Testing Requirements
James Graham , 2011-02-17 11:04 +0100: > On 02/17/2011 09:55 AM, Dominique Hazael-Massieux wrote: > > >(I see that Art documented most of this in > >http://www.w3.org/2008/webapps/wiki/Testing_Requirements but thought > >this ought to be confirmed on the list) > > Is there some way to make put this documentation in some common location > rather than having essentially the same facts documented once for HTML, once > for WebApps, etc.? I just now set up a Wiki page at this URL: http://www.w3.org/wiki/TestInfra/goals That page is editable by anyone with a W3C user account. The existing content there used to be at http://www.w3.org/wiki/WebBrowserTestSuite Perhaps we can either merge the content at http://www.w3.org/html/wg/wiki/Testing and http://www.w3.org/2008/webapps/wiki/Testing_Requirements into that page, or we can set up further subpages and add links to them on that "goals" page. --Mike -- Michael[tm] Smith http://people.w3.org/mike
Re: [FileAPI] readAsDataURL()
On 02/17/2011 06:55 AM, Arun Ranganathan wrote: - Original Message - Step 7 of the FileReader.readAsDataURL() algorithm currently just says: Set the result attribute to be blob's data content represented as a Data URL It should, I think, say something about the using the type of the blob as well as the content of the blob when forming the data:// URL. And similarly, I suppose, for FileReaderSync. Hi David, Can you clarify what you mean here? data:// URLs are pretty well defined (Base64, etc.). -- A* David Arun, I'm assuming that you mean for the resulting data:// URL to have a mime type in it, right? But the spec just says to take the "blob's data content" and doesn't say anything about using the type of the blob when creating the URL. David
Re: [webstorage] Moving Web Storage back to Last Call WD
Ian Hickson , 2011-02-14 10:13 +: > On Sat, 12 Feb 2011, Arthur Barstow wrote: > > > > What high priority work must be done such that this spec is ready to be > > re-published as a new Last Call Working draft? > > Tab, do you know of anything that is blocking redoing an LC? > > (Personally I'm fine with it going to REC yesterday, so...) > > > Bugzilla shows no open bugs for this spec I just now raised a new one: spec for Storage object getItem(key) method does not match implementation behavior http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111 -- Michael[tm] Smith http://people.w3.org/mike
[Bug 12111] New: spec for Storage object getItem(key) method does not match implementation behavior
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111 Summary: spec for Storage object getItem(key) method does not match implementation behavior Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Web Storage (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: m...@w3.org QAContact: member-webapi-...@w3.org CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org http://dev.w3.org/html5/webstorage/#dom-storage-getitem says that "The getItem(key) method must return a structured clone of the current value associated with the given key." but all browsers I've tested return a string representation of the value instead. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [FileAPI] readAsDataURL()
- Original Message - > Step 7 of the FileReader.readAsDataURL() algorithm currently just > says: > > > Set the result attribute to be blob's data content represented as a > > Data URL > > It should, I think, say something about the using the type of the blob > as well as the content of the blob when forming the data:// URL. > And similarly, I suppose, for FileReaderSync. Hi David, Can you clarify what you mean here? data:// URLs are pretty well defined (Base64, etc.). -- A* > > David
Re: Testing Requirements
On 02/17/2011 01:03 PM, Arthur Barstow wrote: On Feb/17/2011 5:04 AM, ext James Graham wrote: On 02/17/2011 09:55 AM, Dominique Hazael-Massieux wrote: (I see that Art documented most of this in http://www.w3.org/2008/webapps/wiki/Testing_Requirements but thought this ought to be confirmed on the list) Is there some way to make put this documentation in some common location rather than having essentially the same facts documented once for HTML, once for WebApps, etc.? Where are the HTML WG's testing requirements and "etc.'s" requirements? There is some test-related text at [1] (and links therein). [1] http://www.w3.org/html/wg/wiki/Testing
Re: Testing Requirements
On Feb/17/2011 5:04 AM, ext James Graham wrote: On 02/17/2011 09:55 AM, Dominique Hazael-Massieux wrote: (I see that Art documented most of this in http://www.w3.org/2008/webapps/wiki/Testing_Requirements but thought this ought to be confirmed on the list) Is there some way to make put this documentation in some common location rather than having essentially the same facts documented once for HTML, once for WebApps, etc.? Where are the HTML WG's testing requirements and "etc.'s" requirements? I am willing to help consolidate common requirements (and to help maintain them). -Art Barstow
Re: Testing Requirements
On 02/17/2011 09:55 AM, Dominique Hazael-Massieux wrote: (I see that Art documented most of this in http://www.w3.org/2008/webapps/wiki/Testing_Requirements but thought this ought to be confirmed on the list) Is there some way to make put this documentation in some common location rather than having essentially the same facts documented once for HTML, once for WebApps, etc.?
Re: Testing Requirements
Hi Marcos, Le mardi 15 février 2011 à 13:19 +0100, Marcos Caceres a écrit : > Can we please get a full rundown of the systems available on test > server. Can we also have all the details about getting access to the > server, etc. Here is what I know off the top of my head: * the content on w3c-test.org reflects automatically the content of a number of selected repositories of dvcs.w3.org ; the selection of repositories can be extended by asking sys...@w3.org and/or Francois (f...@w3.org) * w3c-test.org can be used to host any static files * it can be used to host PHP scripts, but these scripts need to be reviewed/approved by W3C Staff — this is done "transparently", i.e. whenever a PHP script is committed, a number of us get a notification, we review the changes and upon approval the PHP script is updated on the server side * the content of w3c-test.org is also available as www.w3c-test.org , www1.w3c-test.org and www2.w3c-test.org to allow testing cross-domain operations * it is also available under https as https://w3c-test.org/ (I see that Art documented most of this in http://www.w3.org/2008/webapps/wiki/Testing_Requirements but thought this ought to be confirmed on the list) We would rather keep as many of the scripts in PHP to avoid making the set up and maintenance of the server more complicated, but if/when we need to run scripts in another language (e.g. Python), this can be brought back on the table. Dom
