Address review feedback

Clarify wording around default list of command-queues used for command-buffer
enqueue.

Author: EwanC

api/cl_khr_command_buffer.asciidoc

@@ -99,17 +99,17 @@ following reasons:
 
 The command-buffer object has no in-order/out-of-order property set on creation,
 it is out-of-order, and command ordering is defined by the dependencies set when
-commands are created. Command dependencies can be define in 3 ways:
+commands are created. Command dependencies can be defined in 3 ways:
 
 1. Device-side {cl_sync_point_khr_TYPE} synchronization-points, providing an
    explicit list of the commands to depend on.
 2. Appending a {clCommandBarrierWithWaitListKHR} barrier command.
 3. Passing an in-order queue when creating the command, creating an implicit
-   dependency on the any previous command created in the command-buffer using
+   dependency on the previous command created in the command-buffer using
    the same queue.
 
 {clEnqueueCommandBufferKHR} submissions to an out-of-order queue have the same
-execution semantics are other operations enqueued to an out-of-order queue,
+execution semantics as other operations enqueued to an out-of-order queue,
 such as {clEnqueueFillBuffer}, where execution between enqueued operations may
 happen concurrently unless dependencies between the operations are expressed
 with events.
@@ -465,6 +465,8 @@ features:
   * 0.9.5, 2024-07-24
   ** Add a properties parameter to all command recording entry-points
      (provisional).
-  * 0.9.6, 2024-12-13
+  * 0.9.6, 2024-10-02
+  ** Add device query for supported queue properties (provisional).
+  * 0.9.7, 2024-12-13
   ** Refactor queue compatability between command-buffer creation and enqueue
      (provisional).

api/cl_khr_command_buffer_multi_device.asciidoc

@@ -314,4 +314,4 @@ require it.
      functions (provisional).
   * Revision 0.9.2, 2024-12-13
   ** Update clRemapCommandBufferKHR behavior to match cl_khr_command_buffer
-     version 0.9.6 (provisional).
+     version 0.9.7 (provisional).

api/opencl_runtime_layer.asciidoc

@@ -14118,11 +14118,12 @@ the queue is an out-of-order queue, then no extra dependencies on previous
 commands using the same queue are created. All queue properties other than
 {CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE} are ignored for the purposes of command
 creation, with the exception of any vendor extension defined queue properties
-that explcitly define semantics for this purpose.
+that explicitly define semantics for this purpose.
 
-The command-queues used on command-buffer creation must be replaced on
-command-buffer enqueue with the command-queues to execute the command-buffer
-on. These may be different command-queues, provided for each element the
+When enqueuing a command-buffer, a list of command-queues to execute the
+command-buffer on can be passed by the user, otherwise the command-queues set
+on command-buffer creation are used by default for execution. A user passed
+list may contain different command-queues, provided for each element the
 substitute command-queue matches the device and context of the command-queue
 used on command-buffer creation. Each command-queue in the enqueue list must
 also have the minimum properties defined by

xml/cl.xml

@@ -7410,7 +7410,7 @@ server's OpenCL/api-docs repository.
                 <enum name="CL_MEM_DEVICE_ID_INTEL"/>
             </require>
         </extension>
-        <extension name="cl_khr_command_buffer_multi_device" revision="0.9.2" supported="opencl" depends="cl_khr_command_buffer" ratified="opencl" provisional="true" comment="requires cl_khr_command_buffer 0.9.6 or later">
+        <extension name="cl_khr_command_buffer_multi_device" revision="0.9.2" supported="opencl" depends="cl_khr_command_buffer" ratified="opencl" provisional="true" comment="requires cl_khr_command_buffer 0.9.7 or later">
             <require>
                 <type name="CL/cl.h"/>
             </require>