Why's this locking schedule an incorrect one?

[oslon]

Time | T9 Operation     | T10 Operation
--------------------------------------
1    | Read x           | 
2    | Write x          | 
3    |           		| Read x
4    |                  | Write x
5    | 		            | Read y
6    |                  | Write y
7    | Read y           | Commit
8    | Write y          | 
9    | Commit           | 

This is a topic from Database Systems by Thomas M. Connolly and Carolyn E. Begg.

Then, he talks about locking:

Here's the gist about it.

- There are shared lock and exclusive lock.

- Lock is granted as per lock compatibility matrix.

- Lock can be upgraded and downgraded.

(Remember author haven't started 2-PL yet)

Then the author talks something which is my question..

Incorrect Locking Schedule

A valid schedule that may be employed using the previous locking rules is:

S={
write_lock(T9,x),read(T9,x),write(T9,x),unlock(T9,x),
write_lock(T10,x),read(T10,x),write(T10,x),unlock(T10,x),
write_lock(T10,y),read(T10,y),write(T10,y),unlock(T10,y),
commit(T10),
write_lock(T9,y),read(T9,y),write(T9,y),unlock(T9,y),
commit(T9)
}

But I see tons of discrepancies in this locked schedule contradictory to what the author said earlier.

1) As per the book earlier, "A transaction continues to hold a lock until it explicitly releases it either during execution of when it terminates(aborts or commits)", Why is the lock being released before commit(T10) and commit(T9) in this case? Did author just meant that the lock was voluntarily removed by the transaction before committing?