Smaller edits

anspec.txt

@@ -3,7 +3,7 @@
 
 // :regtitle: is explained in
 // http://discuss.asciidoctor.org/How-to-add-markup-to-author-information-in-document-title-td6488.html
-= ANARI^™^ {revnumber} – Specification {apititle}
+= ANARI^™^ {revnumber} – Provisional Specification {apititle}
 :regtitle: pass:q,r[^®^]
 The Khronos{regtitle} ANARI Working Group
 :data-uri:

appendices/credits.txt

@@ -5,7 +5,7 @@
 [[credits]]
 == Credits (Informative)
 
-ANARI 1.0 is the result of contributions from many people and companies
+ANARI 1.1 is the result of contributions from many people and companies
 participating in the Khronos ANARI Working Group, as well as input from the
 ANARI Advisory Panel.
 
@@ -18,7 +18,26 @@ their name.
 
 === Working Group Contributors to ANARI
 
-  * Bill Sherman, NIST
+==== ANARI 1.1
+
+  * Bill Sherman, National Institute of Standards and Technology
+  * Ingo Wald, NVIDIA
+  * Jakob Progsch, NVIDIA
+  * Jefferson Amstutz, NVIDIA
+  * Johannes Günther, Intel
+  * John Stone, NVIDIA
+  * Kees Van Kooten, NVIDIA
+  * Kevin Griffin, NVIDIA
+  * Leonard Daly, Daly Realism
+  * Mirosław Pawłowski, Intel
+  * Neil Trevett, NVIDIA
+  * Simon Su, National Institute of Standards and Technology
+  * Thomas Arcila, NVIDIA
+  * Victor Mateevitsi, Argonne National Laboratory
+
+==== ANARI 1.0
+
+  * Bill Sherman, National Institute of Standards and Technology
   * Brian Savery, AMD
   * Dave DeMarle, Intel
   * Jakob Progsch, NVIDIA
@@ -38,8 +57,9 @@ their name.
 The ANARI Advisory Panel members provided important real-world usage
 information and advice that helped guide design decisions.
 
-Administrative support to the Working Group for ANARI 1.0 was
-provided by Khronos staff.
+Administrative support to the Working Group for ANARI 1.1 was provided by
+Khronos staff including Emily Stearns; and by Alex Crabb of Caster
+Communications.
 
 Technical support was provided by James Riordon, webmaster of Khronos.org.
 

appendices/function_index.txt

@@ -6,6 +6,7 @@
 == Function Index (Informative)
 
 * <<anariCommitParameters, `anariCommitParameters`>>
+* <<ANARIDeleterCallback, `ANARIDeleterCallback`>>
 * <<anariDiscardFrame, `anariDiscardFrame`>>
 * <<ANARIFrameCompletionCallback, `ANARIFrameCompletionCallback`>>
 * <<anariFrameReady, `anariFrameReady`>>
@@ -21,7 +22,6 @@
 * <<anariMapParameterArray1D, `anariMapParameterArray1D`>>
 * <<anariMapParameterArray2D, `anariMapParameterArray2D`>>
 * <<anariMapParameterArray3D, `anariMapParameterArray3D`>>
-* <<ANARIMemoryDeleter, `ANARIMemoryDeleter`>>
 * <<anariNewArray1D, `anariNewArray1D`>>
 * <<anariNewArray2D, `anariNewArray2D`>>
 * <<anariNewArray3D, `anariNewArray3D`>>

chapters/api_concepts.txt

@@ -373,15 +373,14 @@ info cannot be retrieved.
 The following infos of parameters can be queried:
 
 .Info of parameters for introspection.
-[cols="<10,<12,^9,<38",options="header,unbreakable"]
+[cols="<11,<12,^9,<38",options="header,unbreakable"]
 |===================================================================================================
 | Name          | Type        | Required | Description
 | description   | `STRING`    |    No    | explanation of the parameter, e.g., for a tooltip
 | minimum       | type        |    No    | set values will be clamped to this minimum
 | maximum       | type        |    No    | set values will be clamped to this maximum
 | default       | type        |    No    | default value, must be in `minimum`..`maximum` if present
-| required      | `BOOL`      |    Yes   | whether the parameter must be set for an object to be valid,
-                                           must be `FALSE` if a `default` is present
+| required      | `BOOL`      |    Yes   | whether the parameter must be set for an object to be valid, must be `FALSE` if a `default` is present
 | softMinimum   | type        |    No    | typical minimum, must be in `minimum`..`maximum` if present (useful, e.g., for a slider widget)
 | softMaximum   | type        |    No    | typical maximum, must be in `minimum`..`maximum` if present (useful, e.g., for a slider widget)
 | elementType   |`DATA_TYPE_LIST`| for ``ARRAY``s | array of supported element types of the `ANARIArray` parameter, with last element `UNKNOWN`
@@ -393,7 +392,8 @@ The following infos of parameters can be queried:
 .Note
 ====
 The `initializer` flag is only present for devices and represents immutable parameters
-passed during device creation.
+passed during device creation via <<api_concepts_devices,
+`anariNewInitializedDevice`>>.
 ====
 
 

chapters/api_design_choices.txt

@@ -123,7 +123,7 @@ use MPI to enable data-parallel rendering. The overall API usage requirements
 are as follows:
 
 - Applications collectively create the device, frame, and world in lockstep.
-- Each rank creates/modifies the local contents of the
+- Each rank creates and modifies the local contents of the
   <<object_types_world,World>> it has using the ANARI API normally.
 - All ranks collectively render by calling `anariRenderFrame` in lockstep.
 
@@ -151,20 +151,20 @@ with the following additional rules:
 This extension introduces the following additional parameters:
 
 .<<api_concepts_parameters, Parameters>> added to MPI distributed <<object_types_frame,Frame>> objects.
-[cols="<2,<,^,<20",options="header,unbreakable"]
-|===================================================================================================
-| Name            | Type                | Default        | Description
-| mpiCommunicator |`VOID_POINTER`       | MPI_COMM_WORLD | The MPI communicator which the device should treat as the MPI world.
-|===================================================================================================
+[cols="<3,<2,^3,<6",options="header,unbreakable"]
+|=============================================================================================
+| Name            | Type          | Default        | Description
+| mpiCommunicator |`VOID_POINTER` |`MPI_COMM_WORLD`| The MPI communicator which the device should treat as the MPI world.
+|=============================================================================================
 
 [NOTE]
 .Note
 ====
 A more complete description of the problem, ANARI-based solution, and example
 implementation results can be found in the freely available paper:
 [[mpi-parallel-rendering]]
-Wald et al.
-July, 2024
-"Standardized Data-Parallel Rendering using ANARI"
-https://arxiv.org/abs/2407.00179
+Wald et al..
+July, 2024.
+_Standardized Data-Parallel Rendering using ANARI_
+https://arxiv.org/abs/2407.00179.
 ====

chapters/introduction.txt

@@ -167,15 +167,15 @@ IEEE.
 August, 2008.
 _IEEE Standard for Floating-Point Arithmetic_.
 IEEE Std 754-2008.
-https://dx.doi.org/10.1109/IEEESTD.2008.4610935 .
+https://dx.doi.org/10.1109/IEEESTD.2008.4610935.
 
 [[vulkan-samplers]]
 The Khronos® Vulkan Working Group.
-January, 2020
+January, 2020.
 _Vulkan® 1.2 – A Specification_, Section 16.8. Image Sample Operations,
-https://registry.khronos.org/vulkan/ .
+https://registry.khronos.org/vulkan/.
 
 [[gltf-brdf]]
-The Khronos® 3D Formats Working Group
+The Khronos® 3D Formats Working Group.
 _glTF™ 2.0 Specification_, Appendix B: BRDF Implementation
-https://registry.khronos.org/glTF/ .
+https://registry.khronos.org/glTF/.

chapters/object_types.txt

@@ -185,7 +185,7 @@ ANARISurface anariNewSurface(ANARIDevice);
 | Name     | Type     | Default | Description
 | geometry |`GEOMETRY`|         | <<object_types_geometry>> object used by this surface
 | material |`MATERIAL`|         | <<object_types_material>> applied to the geometry
-| visible  |`BOOL`    |    TRUE | surface visibility flag (TRUE visible, FALSE not visible)
+| visible  |`BOOL`    |  `TRUE` | whether the surface is visible
 | id       |`UINT32`  |     -1u | <<frame_channels, extension `KHR_FRAME_CHANNEL_OBJECT_ID`>>, optional user Id, for frame <<frame_channels, channel `objectId`>>
 |===================================================================================================