- From: <bugzilla@jessica.w3.org>
- Date: Fri, 17 Feb 2012 17:25:14 +0000
- To: public-webapps@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16017 Summary: [IndexedDB] editorial changes Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: dave.null@w3.org ReportedBy: odinho@opera.com QAContact: member-webapi-cvs@w3.org CC: mike@w3.org, public-webapps@w3.org Looking through the spec with Joao Eiras, we found a few editorial changes. It's just lots of small stuff, so I'm just putting it all here in one bug :-) --------------- 1 deleteDatabase change: > When invoked, this method must create a request and return it. The created > request has no source. to: > When invoked, this method must create a request and return it. The created > request must implement the IDBOpenDBRequest interface and have its source > set to null. 2 deleteDatabase I'm a bit unsure what the text is doing now, but I've written it to how I understand it: change: > If the steps above are successful, the implementation must set the result of > the request to null and fire a success event at the request. The request will > be an IDBVersionChangeRequest returned by those steps. to: > If the steps above are successful, the implementation must set the result of > the request to null and fire a success event at the request. The event MUST > implement the IDBVersionChangeEvent interface and have oldVersion set to > database version and have the newVersion property set to null. 3 open I don't understand this text. I think it must be wrong. If it's not wrong, it should be much clearer. http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#widl-IDBFactory-open-IDBOpenDBRequest-DOMString-name-unsigned-long-long-version > If an error is returned from the steps above, the implementation must set the > error attribute of the request to a DOMError whose type is the same as the > error returned, of the request to null, and dispatch an event at request. The > event must use the Event interface and have its type set to "error". The > event does bubble but is not cancelable. The propagation path of the event > is just the request. > > If the steps above are successful, the implementation must set the error > attribute of the request to a DOMError whose type is the same as the error > returned, to the connection created by the steps above and dispatch an event > at request. The event must use the Event interface and have its type set to > "success". The event does not bubble and is not cancelable. The propagation > path of the event is just the request. If the steps above resulted in a > VERSION_CHANGE transaction being run, then firing the "success" event must > be done in the same task as was used Waat? I would just delete the second talk about errors and write: > If the steps above are successful, the implementation must dispatch an event > at request. The event must use the Event interface and have its type set to > "success". The event does not bubble and is not cancelable. The propagation > path of the event is just the request. If the steps above resulted in a > VERSION_CHANGE transaction being run, then firing the "success" event must > be done in the same task as was used 4 IDBTransaction.abort, typo http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#widl-IDBTransaction-abort-void change: > steps for aborting a transaction with with the error attribute to: > steps for aborting a transaction with the error attribute 5 IDBTransaction.objectStore, typo http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#widl-IDBTransaction-objectStore-IDBObjectStore-DOMString-name change: > that is part of the to the scope of this transaction. to: > that is part of the scope of this transaction. 6 the the typos Change all 'the the' to 'the'. 7 Transaction Creation steps http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#transaction-creation-steps step 8: change 'synchrnously' to 'synchronously'. 8 Steps for committing a transaction, steps for aborting a transaction Change all occurences of: > All the changes made to the database the transaction uses to: > All the changes made to the database by the transaction 9 Steps for abort a transaction Change 'two parameter' to 'two parameters' 10 Steps for extracting a key from a value using a key path Change, in step 3, 'assignattribute' to 'assign attribute'. 11 VERSION_CHANGE transaction steps change: > This algorithm takes two required parameters - a connection object > which is used to update the database a new version to be set for the > database. The algorithm also takes two optional arguments, a request > which represents a request used when the asynchronous API is used, > or a upgrade callback which represents the callback used when the > synchronous API is used. to: > This algorithm takes two required parameters: a connection object > which is used to update the database, and a new version to be set for > the database. The algorithm also takes two optional arguments: a > request which represents a request used when the asynchronous API is > used, or a upgrade callback which represents the callback used when the > synchronous API is used. So basically, add two colons, and add one "and". 12 VERSION_CHANGE transaction steps Step 2, change: > Fire a versionchange event at each object in openDatabases that is open. to: > Fire a versionchange event at each object in openDatabase that is open. 13 Database deletion steps change: > The steps for deleting a database are as follows. The algorithm > in these steps take three arguments. An origin which requested > the database to be deleted, a database name. It also optionally > takes a request which represents a request used when deleting > the database is done using an asynchronous API. to: > The steps for deleting a database are as follows. The algorithm > in these steps takes three arguments: the origin which requested > the database to be deleted, a database name and an optional > request representing a request used when deleting the database > from an asynchronous API. Changed many small things. 14 Fire a success event change: > The event does not bubble or be cancelable. to: > The event does not bubble and is not cancelable. change: > The propagation path for the event is transaction's connection, to: > The propagation path for the event is the transaction's connection, 15 Fire an error event change: > The event does bubble and is cancelable. to: > The event bubbles and is cancelable. change: > The propagation path for the event is transaction's connection, to: > The propagation path for the event is the transaction's connection, change: > The event's default action is to abort the transaction by > running steps for aborting a transaction. to: > The event's default action is to abort the transaction by > running the steps for aborting a transaction. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Friday, 17 February 2012 17:25:22 UTC