so i'd expect 'for each' instead of 'in that'
> Auto populated index record will also be respectively inserted or updated depending on what storing results in.
records
note that ending a sentence with a preposition (in) is discouraged.
note that you generally use articles a/an for each element in your lists, so while i originally suggested dropping an 'a', you should probably just add the missing one (alternatively you'd need to remove all of the other articles from additional list items
[3.2.3]
> Storing would mean inserting if no record exists for that key or updating an existing record, otherwise.
you haven't updated any automatic indexes 
> Return the a new structured clone of the value in the record with key key in store.
drop 'the'
[3.2.7]
> If any indexes are auto-populated for store, then remove the record in that index according to index maintenance conditions.
see previous comment about 'in that'
[3.2.8]
> Remove the records from index with key key.
oh, this is an index, ok :)
> If these steps are called with an empty array of database objects
this isn't a sentence
> Do not acquire locks on any database objects now.
[context] this looks like a sentence, but is confusing
> Locks are obtained as the application attempts to access those objects.
'those objects' is odd
> Programmers must use caution to acquire and release database objects in the same global order to avoid deadlocks.
deadlock (singular)
or rather, perhaps, uncountable ?
(or state, whatever)
> If a timeout duration is passed to these steps and is exceeded when acquiring locks, then set code to TIMEOUT_ERR and jump to the last step.
'when acquiring' isn't really right, perhaps 'while trying to acquire'
> Open a new transaction to the database, and create a IDBTransaction object that represents that transaction.
an IDBTransaction object representing that transaction
> A database connection can be used to manipulate the objects of that database.
i don't really like 'of that'
> That is also the only means of obtaining a transaction for that database.
change 'That' to 'It' or 'This' ?
i don't like 'of obtaining' it's passive voice, could you rewrite the sentence? :)
(sorry, i know i'm asking a lot)
[removeObjectStore]
> This method is used to destroy an object store with the given name as well as all indexes that are referencing that object store.
drop 'are'
and change 'referencing' to 'reference'
fwiw, it's 1:30am and my eyes are glazing over, so i'm jumping through things faster
> Using the synchronous API, an application can process all the records in the cursor's range. No two values provided by the user agent to callbacks processing data in this cursor can be identical.
i wouldn't write 'can'.
> Example
> By default, a cursor walks over objects starting at the first record and ending at the last record including all the duplicates encountered along the way. If the cursor callback returns true, then the iteration is stopped.
the duplicates bit seems to contradict the previous section, which confuses me :(
It is also possible to create a bounded cursor, i.e., with application-specified starting and ending points, the cursor should be created with both the required keys.

Could someone please summarize what changes are requested here.

I'm having trouble following the conversion, and I also suspect a lot of the relevant text has been modified since.

(In reply to comment #2)
> Could someone please summarize what changes are requested here.
> 
> I'm having trouble following the conversion, and I also suspect a lot of the
> relevant text has been modified since.

This is a laundry list of editing request submitted by Timeless before I came on as an editor. I suspect that you're right, that much of the content has changed, but I REALLY need to go through this list and make sure that no viable comment slips through the cracks unanswered.

There are now further editorial comments from timeless here:

http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0169.html

Eliot: Would be rockin' if you wanted to take this bug. I really couldn't make much sense of the initial comments.

Made the following changes. These are from the mail referenced in comment 4.

> > Transaction
> > A transaction is used to interact with the data in a database.
> > Whenever data is read or written to the database this is done using a transaction.
> 
> maybe s/this/it/

Changed to: Whenever data is read or written to the database it is done by using a transaction. 

> > All transactions are created using a connection,
> 
> I don't like "using", perhaps "from"? -- I haven't gotten to the API yet.
> I'm also uncertain about 'a connection' vs. 'connections'
> 
> > which is the transactions connection.
> 
> s/transactions/transaction's/
> 

Changed to: All transactions are created through a connection, which is the transaction's connection.

> > The transaction has a mode which determines which types of
> > interactions can be performed using the transaction.
> 
> s/using the transaction/upon it/ ? -- "The transaction" also started the
> sentence.

Changed to: The transaction has a mode that determines which types of interactions can be performed upon that transaction.

> 
> > The mode is set when the transaction is created and remains constant
> > for the
> 
> s/constant/fixed/
> 
> > lifetime of the transaction.
> 
> s/lifetime/life/

Changed to: The mode is set when the transaction is created and remains fixed for the life of the transaction.

> 
> > The transaction also has a scope which determines which object stores
> > the transaction can interact with.
> 
> s/which.*with/the object stores with which the transaction may interact/.

Changed to: The transaction also has a scope that determines the object stores with which the transaction may interact.

> 
> > Finally, transactions have a active flag,
> 
> s/ a / an /
> s/Finally, t/T/ -- It isn't Finally -- Finally is used again in the next sentence.
> 
> > which determines if new requests can currently be placed against the
> transaction.
> 
> The prose here implies that this is mutable, it's also awkward (probably he
> use of 'currently').

Changed to:  Transactions have an active flag, which determines if new requests can be made against the transaction.

> 
> > Finally, transactions also contain a request list of requests which have been
> placed against the transaction.
> 
> It seems that <placed> is treated as technical language, I'd expect it to be
> defined somewhere (or globally replaced by 'made').

Changed to:  Finally, transactions also contain a request list of requests which have been made against the transaction.

> 
> > Transactions have a constant scope which is determined when the
> > transaction is created and remains constant for the lifetime of the
> transaction.
> 
> Each transaction has a fixed scope determined at creation time.

Changed to: Each transaction has a fixed scope, determined when the transaction is created. A transaction's scope remains fixed for the lifetime of that transaction.

Made the following changes. The suggestions are from the mail referenced in comment 4.


> >  A transaction represents an atomic and durable set of data access and
> mutation operations.
> 
> I know that data can be uncountable or plural, but I'm unsure that 'access'
> fits with its use here -- should it be 'accesses'?

Changed to:  A transaction represents an atomic and durable set of data access and data mutation operations. 
data access and data mutation describe operations. access is correct.

Note: Also changed the sentence containing the other instance of mutation in the spec.
(IDBDatabaseException CONSTRAINT_ERR  exceptions description) Was: A mutation operation in the transaction failed due to a because a constraint was not satisfied.
Changed to: A mutation operation in the transaction failed because a constraint was not satisfied.


> 
> > This is encouraged using the automatically committing functionality
> described below.
> 
> s/using the automatically/by the automatic/
> 
> > Authors can still cause transactions to run for a long time, however
> > this is generally not a usage pattern which is recommended
> 
> s/usage pattern which is recommended/a recommended usage pattern/
> 
> > and can lead to bad user experience in some implementations.
> 
> possibly <a bad user experience> | <bad user experiences> ?

Changed to:  Transactions are expected to be short lived. This is encouraged by the automatic committing functionality described below. Authors can still cause transactions to run for a long time; however, this usage pattern is not generally recommended as it can lead to a bad user experience.


> 
> > A transaction is created using IDBDatabase.transaction.
> > The arguments passed determine what the scope of the transaction is
> 
> s/what//; s/is//
> 
> > and whether it's read only or not.
> 
> whether or not it is read-only.

Changed to:  A transaction is created using IDBDatabase.transaction. The arguments passed determine the scope of the transaction and whether the transaction is read-only.


> 
> > Until the transaction is started the implementation MUST NOT execute
> > these requests, but the implementation MUST still keep track of the
> > requests and their order.
> 
> s/, but/;/
> s/still//

Changed to: Until the transaction is started the implementation MUST NOT execute these requests; however, the implementation MUST keep track of the requests and their order.


> 
> > Requests may only be placed against the transaction
> 
> s/the/a/
> 
> > while the transaction is active.
> 
> s/the transaction/it/
> 
> > If a request is attempted to be placed against a transaction when
> 
> I find <request/attempted/placed> awkward, possibly because it lacks an
> actor...
> 
> > it is not active,
> 
> I believe <not active> is used here to be the technical state <not <active>>,
> perhaps it should be marked up. Otherwise as this is prose, I'd use <inactive>.
> 
> > the implementation MUST reject the attempt by throwing a
> TRANSACTION_INACTIVE_ERR exception.
> 
> Inactive is used in the exception type, it's a valid English word....

Changed to:  Requests may be placed against a transaction only while that transaction is active. If an attempt is made to place a request against a transaction when that transaction is not active, the implementation MUST reject the attempt by throwing a TRANSACTION_INACTIVE_ERR exception.


> 
> > Once an implementation is able to enforce the constraints defined for
> > the mode of the transaction,
> 
> transaction mode
> 
> > defined below, the implementation MUST asynchronously start the
> transaction.
> 
> > When this happens is affected by the mode in which the transaction is
> > opened, and which object stores are included in scope of the transaction.
> 
> s/which/the/
> s/are//
> s/scope of the transaction/the transaction's scope/

Changed to: Once an implementation is able to enforce the constraints defined for the transaction mode, defined below, the implementation MUST asynchronously start the transaction. The timing for when this happens is affected by: 
	The mode in which the transaction is opened.
	Which object stores are included in the scope of the transaction.

> 
> > Once the transaction has been started the implementation can start
> executing the requests placed against the transaction.
> > Unless otherwise defined requests MUST be executed in the order they
> > are placed against the transaction.
> 
> s/they/in which they/
> s/are/were/
> 
> I find <placed> <against> strange. <made> <against> seems to work
> Otherwise <placed> <into>
> 
> > Likewise, their result MUST be returned in the order the request was
> > placed against a specific transaction.
> 
> <result> appears to be used as a mass noun, but <request> is singular, I'm
> pretty sure this doesn't work.
> 
> > There is no guarantee about the order that results from requests in
> > different transactions are returned.
> 
> > Similarly, the isolation mode ensure that
> 
> ensures
> 
> > it doesn't matter which order requests placed against different transactions
> are executed.
> 
> order of requests placed against different transactions doesn't matter with
> respect to execution order.
> 
> I don't like "matter", do you mean 'affect'?

Changed to:  Once the transaction has been started the implementation can start executing the requests placed against the transaction. Unless otherwise defined, requests MUST be executed in the order in which they were made against the transaction. Likewise, their results MUST be returned in the order the requests were placed against a specific transaction. There is no guarantee about the order that results from requests in different transactions are returned. Similarly, the transaction mode ensures that the order of requests placed against different transactions has no effect with respect to execution order.


> 
> > At any time a transaction can be aborted,
> 
> A transaction can be aborted at any time,
> 
> > even if the transaction isn't currently active.
> 
> Again, <inactive> would be better.
> 
> > When a transaction is aborted
> 
> When <actor requests to abort a transaction>....
> 
> -- aborted is the result of the request plus the action taken by the agent
> 
> > the implementation MUST undo (roll back) any changes made to the
> > database using the transaction.
> 
> s/using/from|in/ ?
> 
> > This includes both changes to the contents of object stores as well as
> > additions and removals of object stores and indexes.

Changed to: A transaction can be aborted at any time, even if the transaction isn't currently active. When a transaction is aborted the implementation MUST undo (roll back) any changes that were made to the database during that transaction. This includes both changes to the contents of object stores as well as additions and removals of object stores and indexes.

(In reply to comment #4)
> There are now further editorial comments from timeless here:
> 
> http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0169.html
> 
> Eliot: Would be rockin' if you wanted to take this bug. I really couldn't make
> much sense of the initial comments.

There are more from timeless here:

http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0288.html

Changes made based on feedback in the mail referenced in comment 4. This completes the feedback from that particular mail:

> > A transaction can be aborted at any time before it is finished. Including if it
> isn't active or hasn't yet started.
> 
> This duplicates text from the beginning of the point and should be folded into
> the original statement.


Removed the note and changed to:
A transaction can be aborted at any time before it is finished, even if the transaction isn't currently active or hasn't yet started.


> 
> > Once a transaction no longer can become active,
> 
> s/Once/When/
> s/no longer can/can no longer/
> 
> > and if the transaction hasn't been aborted,
> 
> Move this to the start of the sentence
> 
> > the implementation MUST automatically attempt to commit it.
> 
> I think <automatically> can be dropped
> 
> > This usually happens after all requests placed against the transaction
> > has been executed and their returned results handled,
> 
> s/has/have/
> 
> > but no new requests has been placed against the transaction.
> 
> s/but/and/
> s/has/have/
 
Changed to:
When a transaction can no longer become active, the implementation must attempt to commit it, as long as the transaction has not been aborted. This usually happens after all requests placed against the transaction have been executed and their returned results handled, and no new requests have been placed against the transaction.

>
> > When a transaction is committed implementation
> 
> s/committed/committed,/
> 
> > MUST atomically write any changes to the database made by requests
> placed against the transaction.
> 
> > That is, either all of the changes MUST be written, or if an error occurs,
> such as a disk write error, the implementation MUST NOT write any of the
> changes to the database.
> 
> I think "write ... to the database" isn't ideal here, what we want is for none
> of the changes to appear in the database when queried. It's certainly possible
> for bits to be written to a portion of the database which is rolled back, but
> that's still a "write" in a naive sense.
> 
> > If such an error occurs the implementation
> 
> s/occurs/occurs,/
> 
> > MUST abort the transaction by following the steps for aborting a
> > transaction, otherwise it MUST commit the transaction by following the
> > steps for committing a transaction.
> 
> > When a transaction is committed or aborted, it is said to be finished.
> > If a transaction can't be finished, for example due to the
> > implementation crashing or the user taking some explicit action to
> > cancel it, the implementation MUST abort the transaction.
> 
> <abort> here can't mean <take the steps for aborting a transaction> in the
> case where the implementation crashes.
Changed to:
When a transaction is committed, the implementation must atomically write any changes to the database made by requests placed against the transaction. That is, either all of the changes must be written, or if an error occurs, such as a disk write error, the implementation must not write any of the changes to the database. If such an error occurs, the implementation must abort the transaction by following the steps for aborting a transaction, otherwise it must commit the transaction by following the steps for committing a transaction.



> 
> > Transactions are opened in one of three modes.
> > The mode determine how concurrent access to
> 
> determines
> 
> > object stores in the transaction is isolated.
> 
> s/is/are/
> 
Changed to:
Transactions are opened in one of three modes. The mode determines how concurrent access to object stores in the transaction are isolated.

Made the following changes. The suggestions are from the mail referenced in comment 7.

> The transaction mode determines both which operations are allowed to 
> be performed during the transaction, as well whether two transactions 
> can run concurrently or not.
The transaction mode controls whether or not multiple transactions can run currently and which operations may be performed during the transaction.
> Which operations are allowed be be performed are
The allowed operations are
> defined in detail below,
> but in general transactions opened in READ_ONLY mode are only allowed 
> to perform reading operations which does not change data.
s/reading //
s/does/do/
-- this defines read, and operations are plural.. if you really want to define it perhaps stick some quotes around reading?
> READ_WRITE transactions are allowed to
> perform reading and writing transactions to existing object stores,
s/perform reading and writing/read from and write/
> where as VERSION_CHANGE transactions are allowed to perform any operations, including ones that delete and create object stores and indexes.

Changed to:
The transaction mode controls whether or not multiple transactions can run currently and which operations may be performed during the transaction. The allowed operations are defined in detail below, but in general transactions opened in READ_ONLY mode are only allowed to perform operations that do not change data. READ_WRITE transactions are allowed to perform reading and writing transactions to existing object stores, where as VERSION_CHANGE transactions are allowed to perform any operations, including ones that delete and create object stores and indexes.

> As long as the VERSION_CHANGE transaction, the implementation
s/transaction/transaction is pending/
?
> MUST wait with starting any other transactions against the same
s/with/before/
> database until the VERSION_CHANGE transaction is finished.
Changed to:
As long as the VERSION_CHANGE transaction is pending, the implementation must wait before starting any other transactions against the same database until the VERSION_CHANGE transaction is finished.

> There are a number of ways that an implementation ensure this.
s/ensure/ensures/
> It can prevent READ_WRITE transactions whose scope overlap
s/prevent/stall/
?
(you don't prevent them from ever existing, you at best prevent them from starting which seems more like stalling or delaying)
s/overlap/overlaps/
> the scope of the READ_ONLY transaction from starting until the 
> READ_ONLY transaction is finished.
s/is finished/finishes/
> Or it can allow the READ_ONLY transaction to see a snapshot of the 
> contents of the object stores which is taken when the READ_ONLY 
> transaction is started.
s/is //
Changed to:
There are a number of ways that an implementation ensures this. The implementation can prevent any READ_WRITE transaction, whose scope overlaps the scope of the READ_ONLY transaction, from starting until the READ_ONLY transaction finishes. Or the implementation can allow the READ_ONLY transaction to see a snapshot of the contents of the object stores which is taken when the READ_ONLY transaction started.

> Similarly, implementations MUST ensure that a READ_WRITE transaction is only affected by changes to object stores that are made using the transaction itself. I.e. the implementation MUST ensure that another transaction does not modify the contents of object stores in the READ_WRITE transactions scope.
I don't think starting a sentence with "i.e." is a good idea...
s/transactions/transaction's/
> The implementation MUST also ensure that if the READ_WRITE transaction 
> completes successfully, that the changes written to object stores 
> using the
s/, that / /
> transaction can be committed to the database without merge conflicts.
i find "can be" here problematic, i know it's only meaningful with the next sentence, but i don't think it works well.
> An implementation MUST NOT abort a transaction due to merge conflicts.
Changed to:
Similarly, implementations must ensure that a READ_WRITE transaction is only affected by changes to object stores that are made using the transaction itself. For example, the implementation must ensure that another transaction does not modify the contents of object stores in the READ_WRITE transaction's scope. The implementation must also ensure that if the READ_WRITE transaction completes successfully, the changes written to object stores using the transaction can be committed to the database without merge conflicts. An implementation must not abort a transaction due to merge conflicts.

Made these two changes per requests in document cited in comment 4.

> An implementation MUST NOT start any transaction until all other 
> READ_WRITE transactions with overlapping scope have completed.
doesn't this prevent merge conflicts?
> When multiple transactions are eligible to be started, older 
> transactions should be started first.
should 'should' be written as an RFC word?
Changed to:
An implementation must not start any transaction until all other READ_WRITE transactions with overlapping scope have completed. When multiple transactions are eligible to be started, older transactions should be started first.


> User agents MUST ensure a reasonable level of fairness across transactions to prevent starvation.
> For example if multiple READ_ONLY transaction are started one after another the implementation MUST ensure that that doesn't indefinitely prevent a pending READ_WRITE transaction from starting.
This MUST doesn't seem testable, and sticking a MUST into an example seems wrong.
Changed to:
User agents must ensure a reasonable level of fairness across transactions to prevent starvation. For example, if multiple READ_ONLY transactions are started one after another the implementation must not indefinitely prevent a pending READ_WRITE transaction from starting.

Made these changes per requests in document cited in comment 4.

> Transaction objects implement
Each transaction object will implement either
> the IDBTransaction or the IDBTransactionSync
> interfaces.
interface.
-- this is a style change and applies to other objects in this document. I'm assuming that an object only ever implements one of the two interfaces and thus <interface> should be singular and you should spell out that it's exclusive. If it isn't, I'd like to know how/why.
Changed to:
Each transaction object implements either the IDBTransaction or the IDBTransactionSync interface.

> Every request also has a result and an errorCode, neither of which are accessible until the done flag is set to true.
does 'are accessible' mean "will throw an exception if poked"?
STET

> Finally, requests have a request transaction. When a request is created, it is always placed against a transaction using either the steps to asynchronously execute a request or the steps to a synchronously execute a request.
It would be really helpful if things like <steps to whatever> were links
Changed to:
Both links work

> This sets the request transaction to be that request.
s/This sets/Those steps set/
Changed to:
The steps set the request transaction to be that request.

> The only exceptions to this are the request returned from a IDBFactory.open call and the request returned from a IDBDatabase.setVersion call, which create requests which have a null request transaction.
"exceptions" sometimes is an English word and sometimes it's a code term (something which can be thrown). I can't tell here which is intended, if the latter it should be used with 'thrown', for the former I'd suggest avoiding the word entirely.
Changed To:
The steps do not set the request transaction to be that request for the request returned from a IDBFactory.open call or the request returned from a IDBDatabase.setVersion call, however. Those calls create requests which have a null request transaction.

> A key range MAY be lower-bounded or upper-bounded if there is a value that is, respectively, smaller than or larger than all its elements.
"larger" seems odd, is there something wrong with using "greater" (and thus "less")?
Change:
STET. Larger and smaller are preferred when comparing numbers or values. 

> The cursor has a source indicating which index or object store whose records it is iterating.
s/which/the/
s/object/the object/
Changed to:
The cursor has a source that indicates which index or object store is associated with the records over which the cursor is iterating.

> A cursor maintains a position over this series, which moves in a direction that is either monotonically increasing or decreasing order of the record keys.
"order" feels out of place here
Changed to:
A cursor maintains a position over this series, which moves in a direction that is either monotonically increasing or decreasing order of the record keys.

> If the source of a cursor is a object store,
s/a object/an object/
> the effective key of the cursor is the cursors position.
s/cursors/cursor's/
> If the source of a cursor is a index,
s/a index/an index/
> the effective object store of the cursor is that index's referenced object store and the effective key is the cursors object store position.
s/cursors/cursor's/
Changed to:
If the source of a cursor is an object store, the effective object store of the cursor is that object store and the effective key of the cursor is the cursor's position. If the source of a cursor is an index, the effective object store of the cursor is that index's referenced object store and the effective key is the cursor's object store position.

> For cursors iterating indexes the situation is a little bit more complicated since multiple records can have the same key and are therefor also sorted by value.
s/therefor/therefore/
changed


> When iterating indexes the cursor's also has a object store position,
s/cursor's/cursor/
s/a object/an object/
> which indicates the value of the previously found record in the index.
changed

> Both position and the object store position is used when finding the next appropriate record.
s/is/are/
changed

>     A mutation operation in the transaction failed due to a because a 
> constraint was not satisfied.
s/due to a //
changed

> For example, an object such as an object store or index already exists 
> and
> a new one was being attempted to be created.
a request attempted to create a new one.
Changed to:
For example, an object such as an object store or index already exists and a request attempted to create a new one.

Made the following changes. These are from the mail referenced in comment 4.

> A key range is said to be bounded if it is both lower- and upper-bounded and unbounded otherwise.
s/ and unbounded otherwise/; otherwise it is unbounded/ ?
> A key range MAY be open, i.e., not including its endpoints or
s/endpoints/endpoints,/
> closed, i.e., including its endpoints.
>    Either ... and either of the bounds are open.
s/are/is/
Changed to:
A key range may be lower-bounded or upper-bounded (there is a value that is, respectively, smaller than or larger than all its elements). A key range is said to be bounded if it is both lower-bounded and upper-bounded. If a key range is neither lower-bounded nor upper-bounded it is said to be unbounded. A key range may be open (the key range does not include its endpoints) or closed (the key range includes its endpoints). A key range may consist of a single value.

> const unsigned short DATA_ERR = 5
>    Data provided to an operation does not meet requirements.
>This seems like an odd error name given its description
Stet

> A operation
>An operation was
> called on an object on which it is not allowed or at a time when it is not allowed.
Changed to: 
An operation was..

Made the following change. This is from the mail referenced in comment 4 and completes all of the issues raised in that mail.

> The TRANSACTION_INACTIVE_ERR and READ_ONLY_ERR errors are more specific variants of this error.
Does that mean that they should be dispatched instead when applicable?
Or can the UA choose to always use this one?

Changed to:
The TRANSACTION_INACTIVE_ERR and READ_ONLY_ERR errors are more specific variants of this error and should be dispatched instead of this error when possible.

This final batch addresses the issues in the original post to this bug and Comment 1 of this bug.

I believe that takes care of all of the issues raised in this bug, and so I am resolving it as fixed. The final batch are published in changeset 227 for the IndexedDB Editor's Draft. Thanks.

Responses:

> so, i had trouble following the last part 'the key applicable for some 
> index that references that object store'
> i don't see how that precise thing actually gives me the right 
> individual record it maybe be 'some applicable key for an index that 
> references it in its object store'
> but i'm not sure
Cannot find the reference. May have been changed already due to another reason.

> > A key range is a continuous interval over some data type used for keys.
> can you write 'some key <ref>data type</ref>' ?
Wont fix. Will make the construction possibly confusing to non-English readers. 

> > A key range may be left-bounded or right-bounded if there is a value 
> > that is,
> respectively, smaller than or larger than all its elements.
> i think less/greater, but i'm not certain (it's midnight, i'm 
> exhausted, and sick, and have a headache)
> > A key range is said to be bounded if it is both left- and 
> > right-bounded and
> unbounded otherwise.
> 'otherwise unbounded'
> > A valid key range must be either half-bounded or bounded.
> i don't think you've defined 'half-bounded'
Changed as described in comment 12

> > The storage operations are performed on the underlying index or an 
> > object
> store.
> I think you can omit 'The'
Removed The

> > A cursor comprises a range of records in either an index or an object store.
> A cursor maintains a position over this series, which moves in a 
> direction that is either monotonically increasing or decreasing order of the record keys.
> you start by talking about a 'range' and then switch to a 'series'
Description has been expanded to cover this transition.

> > If the scope is static, it can cover either all the object stores 
> > and indexes in a
> database or it may include a subset of them.
>  and if it's dynamic?
Language has been removed some time in the past

> > A connection may have at most one transaction at any given time.
> i think you need a word before 'at'
> something like 'open' or 'running' or 'active'
The referenced content is no longer in the spec.

> > Moreover, there may not be any overlap among the scopes of all open
> connections to a given database.
> this is confusing
> if scopes are limited to transactions, then i think it'd be better to 
> say 'among the scope of all (active?) transactions to a given database'
> or perhaps scopes
The discussion of scope and overlap has been expanded and rewritten (in the past) in section 3.1.7 Transaction.

> > Conforming user agents may terminate transactions that take too long 
> > to
> complete in order to free up storage resources that are locked by a 
> long running transaction.
> the may is interesting, as a useragent, i'd be tempted to terminate 
> transactions that take too much ram :)
This language is no longer in the spec.

> > 3.2.1 Opening the database
> should it be 'a' ?
Why yes; yes, it should. Changed.

> > The steps for opening a database are as follows.
> the first thing that follows isn't a step
> > These steps must be run with an origin, a database name and description.
> drop 'a' from before 'database', or add 'a' before 'description'
Changed to the following:
The steps for opening a database are defined in the following steps. The algorithm in these steps takes two arguments: an origin, which requested the database to be opened, and a database, name. The algorithm also optionally takes a request which represents a request used when opening the database is done by using an asynchronous API.


> > All the steps must be run atomically:
> drop 'the'?
> note that i'm not sure what 'All' means here does it mean that each 
> step is atomic, or the effect of the entire set of steps is atomic?
> > If there is already a database with the given name from the origin 
> > origin
> origin origin :(
Language has been previously removed from the spec.

> > 3.2.2 Object Store Storage steps
> 3.2.1 didn't include 'steps', why does 3.2.2?
Previously changed

> > These steps must be run with four parameters: the object store, a 
> > value, an
> optional key, and an optional no-overwrite flag.
> 'must'/'four' seems odd given that two are optional
Changed in the past: No more must

> > If store uses out-of-line keys but no key generator, then a key must 
> > be
> passed to these steps. If not, terminate these steps and set error 
> code DATA_ERR.
> i think it'd rather this be one if condition If 
> (store.uses(out_of_line_keys) &
> !store.has_(key_generator) & !key) then terminate()
This text has been removed sometime in the past.

> > If store uses in-line keys, then let key be the property of object 
> > at store's key
> path.
> what happens if 'key' was an argument?
This text has been removed sometime in the past.

> > Using store's key generator, produce the next key and store it as key.
> i'd avoid using the phrase 'store it'
This text has been removed sometime in the past

> > If store uses in-line keys, then store key as the property value for 
> > object at
> store's key path.
> using 'store' 3 times in a sentence with sometimes different meanings 
> is really confusing :(
Agreed. Thankfully, this text has been removed sometime in the past.

> > If any indexes are auto-populated for store, then store a record in 
> > that
> index according to index maintenance conditions.
> 'any indexes' is plural
This text has been removed sometime in the past.

> Comment 1:
> so i'd expect 'for each' instead of 'in that'
> > Auto populated index record will also be respectively inserted or 
> > updated
> depending on what storing results in.
> records
> note that ending a sentence with a preposition (in) is discouraged.
> note that you generally use articles a/an for each element in your 
> lists, so while i originally suggested dropping an 'a', you should 
> probably just add the missing one (alternatively you'd need to remove 
> all of the other articles from additional list items [3.2.3]
Cannot locate text. This has been changed or removed previously.

> > Storing would mean inserting if no record exists for that key or 
> > updating an
> existing record, otherwise.
> you haven't updated any automatic indexes 
> > Return the a new structured clone of the value in the record with 
> > key key in
> store.
> drop 'the'
Cannot locate text. This has been changed or removed previously.

> [3.2.7]
> > If any indexes are auto-populated for store, then remove the record 
> > in that
> index according to index maintenance conditions.
> see previous comment about 'in that'
Cannot locate text. This has been changed or removed previously.


> [3.2.8]
> > Remove the records from index with key key.
> oh, this is an index, ok :)
> > If these steps are called with an empty array of database objects
> this isn't a sentence
Cannot locate text. This has been changed or removed previously.


> > Do not acquire locks on any database objects now.
> [context] this looks like a sentence, but is confusing
Cannot locate text. This has been changed or removed previously.


> > Locks are obtained as the application attempts to access those objects.
> 'those objects' is odd


> > Programmers must use caution to acquire and release database objects 
> > in
> the same global order to avoid deadlocks.
> deadlock (singular)
> or rather, perhaps, uncountable ?
> (or state, whatever)

> > If a timeout duration is passed to these steps and is exceeded when
> acquiring locks, then set code to TIMEOUT_ERR and jump to the last step.
> 'when acquiring' isn't really right, perhaps 'while trying to acquire'
> > Open a new transaction to the database, and create a IDBTransaction 
> > object
> that represents that transaction.
> an IDBTransaction object representing that transaction
Changed a to an in IDBDatabase.transaction(). Sync version, too. Other than that, cannot find this text.

> > A database connection can be used to manipulate the objects of that
> database.
> i don't really like 'of that'
Stet.

> > That is also the only means of obtaining a transaction for that database.
> change 'That' to 'It' or 'This' ?
> i don't like 'of obtaining' it's passive voice, could you rewrite the sentence?
> :)
> (sorry, i know i'm asking a lot)
Changed to:
A database object can be used to manipulate the objects of that database. It is also the only way to obtain a transaction for that database.

> [removeObjectStore]
> > This method is used to destroy an object store with the given name 
> > as well
> as all indexes that are referencing that object store.
> drop 'are'
> and change 'referencing' to 'reference'
deleteObjectStore() now says:
This method destroys the object store with the given name in the connected database as well as all indexes that reference that object store.

> fwiw, it's 1:30am and my eyes are glazing over, so i'm jumping through 
> things faster
> > Using the synchronous API, an application can process all the 
> > records in the
> cursor's range. No two values provided by the user agent to callbacks 
> processing data in this cursor can be identical.
> i wouldn't write 'can'.
> > Example
> > By default, a cursor walks over objects starting at the first record 
> > and ending
> at the last record including all the duplicates encountered along the 
> way. If the cursor callback returns true, then the iteration is stopped.
> the duplicates bit seems to contradict the previous section, which 
> confuses me :( It is also possible to create a bounded cursor, i.e., 
> with application- specified starting and ending points, the cursor 
> should be created with both the required keys.
Previously implemented in the spec. See section 3.3.5 Cursor