Address editorial PR feedback

Author: Ewan Crawford

api/cl_khr_command_buffer.asciidoc

@@ -3,8 +3,6 @@
 
 include::{generated}/meta/{refprefix}cl_khr_command_buffer.txt[]
 
-// *Revision*::
-//    0.9.7
 // *Extension and Version Dependencies*::
 //     This extension requires OpenCL 1.2 or later.
 //     Buffering of SVM commands requires OpenCL 2.0 or later.
@@ -132,11 +130,6 @@ command-buffer. However, simultaneous use may result in command-buffers having
 a larger overhead to implement, so the capability is optional to enable
 optimizations when this usage isn't required by a user.
 
-Instead the goal for the base level of functionality provided by the extension
-is to support pipelined workflows. Where a command-buffer is repeatedly
-enqueued, with each enqueue expressing dependencies on any previous submissions,
-without the enqueue calls blocking in user code.
-
 === Interactions With Other Extensions
 
 The introduction of the command-buffer abstraction enables functionality

api/opencl_runtime_layer.asciidoc

@@ -14618,14 +14618,14 @@ on one or more command-queues without any application code interaction.
 Grouping the operations together allows efficient enqueuing of repetitive
 operations, as well as enabling driver optimizations.
 
-Upon creation a command-buffer is defined as being in the <<recording,
-Recording>> state, in order for the command-buffer to be enqueued
-it must first be finalized using {clFinalizeCommandBufferKHR} after which no
-further commands can be recorded. A command-buffer is submitted for execution
-on command-queues with a call to {clEnqueueCommandBufferKHR}. It is
-always valid to call {clEnqueueCommandBufferKHR} with a command-buffer that
-has previously been enqueued, provided the call doesn't violate the definition
-of <<simultaneous-use, simultaneous use>>.
+Upon creation a command-buffer is in the <<recording, Recording>> state. In
+order for the command-buffer to be enqueued it must first be finalized using
+{clFinalizeCommandBufferKHR}, after which no further commands can be recorded.
+A command-buffer is enqueued for execution on command-queues with a call to
+{clEnqueueCommandBufferKHR}. It is always valid to call
+{clEnqueueCommandBufferKHR} with a command-buffer that has previously been
+enqueued, provided the call doesn't violate the definition of
+<<simultaneous-use, simultaneous use>>.
 
 Command-buffers are created using an ordered list of command-queues that
 commands are recorded to and execute on by default. All these queue objects
@@ -14702,13 +14702,16 @@ Simultaneous Use:: When a command-buffer is submitted for
 execution without a prerequisite on all the previous submissions of the same
 command-buffer which are not in the {CL_COMPLETE} state.
 
+[NOTE]
+====
 An example of simultaneous use would be two submissions of the same
 command-buffer to a single out-of-order queue, without any events or barriers
 used to express a dependency between the two enqueue calls. Using a single
 in-order queue, events, or barriers to express dependencies between submissions
 of the same command-buffer would each be ways to avoid simultaneous use and are
 valid usage of command-buffers created without the
 {CL_COMMAND_BUFFER_SIMULTANEOUS_USE_KHR} flag.
+====
 
 ifdef::cl_khr_command_buffer_multi_device[]
 === Command-Buffers and Multiple Devices