[Bug 16017] New: [IndexedDB] editorial changes

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