fixes suggested by @judax

explainer.md

@@ -12,9 +12,9 @@ The main idea behind the concept of an anchor is that as the underlying platform
 *   **Anchor**: a concept that allows developers to specify a pose that can change over time either because the system's understanding of the physical world coordinates changes, or because the understanding of an object in the world the anchor is relative to changes.
     *   **Important note about the concept of anchor in Apple's iOS [ARKit](https://developer.apple.com/documentation/arkit) and in this explainer:** iOS ARKit's SDK uses the concept of an anchor to represents 2 ideas at the same time:
         1.  An arbitrary pose in 3D space that needs to be updated relative to the physical world. Anchors that represent an arbitrary pose can be created and registered in ARKit. This is the same as the anchor concept in this explainer.
-        1.  A real world object that the system is able to identify from the real world understanding. These elements have have a pose, but also include other information such as geometry. At the moment of the publication of this explainer ARKit is able to understand [ARPlaneAnchor](https://developer.apple.com/documentation/arkit/arplaneanchor), [ARFaceAnchor](https://developer.apple.com/documentation/arkit/arfaceanchor) and [ARImageAnchor](https://developer.apple.com/documentation/arkit/arimageanchor) as anchors.
+        1.  A real world object that the system is able to identify from the real world understanding. These elements have a pose, but also include other information such as geometry. At the moment of the publication of this explainer ARKit is able to understand [ARPlaneAnchor](https://developer.apple.com/documentation/arkit/arplaneanchor), [ARFaceAnchor](https://developer.apple.com/documentation/arkit/arfaceanchor) and [ARImageAnchor](https://developer.apple.com/documentation/arkit/arimageanchor) as anchors.
 
-        While ARKit uses the concept of an anchor to represent the pose and the identified real world object, this explainer currently uses the term anchor to only represent an object with a poses that specifies it's location relative to the physical world. The [ARAnchor](https://developer.apple.com/documentation/arkit/aranchor) (1) base class in ARKit would be equivalent of the concept of an anchor in this explainer. Additional information about the representation of real world objects is out of the scope of this explainer. This differentiation between the concept of an anchor in ARKit and in the scope of this explainer is subtle but important.
+        While ARKit uses the concept of an anchor to represent the pose and the identified real world object, this explainer currently uses the term anchor to only represent an object with a pose that specifies it's location relative to the physical world. The [ARAnchor](https://developer.apple.com/documentation/arkit/aranchor) (1) base class in ARKit would be equivalent of the concept of an anchor in this explainer. Additional information about the representation of real world objects is out of the scope of this explainer. This differentiation between the concept of an anchor in ARKit and in the scope of this explainer is subtle but important.
 
 
 # Scope
@@ -30,34 +30,36 @@ Anchors could also represent entities with poses that:
 3.  Persist, meaning that the anchor is able to live between executions of the same application.
 4.  Are shared between different applications.
 
+The two uses are currently out of the scope of the anchor proposal.
+
 This explainer focuses on just the first concept of anchors (1) as specifying the pose of a location in the world, but leaves open the possibility for anchors knowing their relationship to semantically meaningful parts of the physical real world that the system has detected (2). 
 
-Creating anchors in relation to the structure of the physical world around the user (such as if the system supports intersecting a ray with the the systems understanding of the physical world) is a very common practice practice that we want to support.
+Creating anchors in relation to the structure of the physical world around the user (such as if the system supports intersecting a ray with the system's understanding of the physical world) is expected to be a very common practice.
 
 The reasons for this limited scope are:
 
-*   Arbitrary anchors are the most basic yet useful type of anchors. There is always a need, no matter the granularity of the real world understanding the system has, to create arbitrary 3D poses as anchors. Moreover, arbitrary 3d pose anchors can be used to represent positions relative to detect or tracked objects when world understanding is expended to include object detection and tracking.
+*   Arbitrary anchors are the most basic yet useful type of anchors. There is always a need, no matter the granularity of the real world understanding the system has, to create arbitrary 3D poses as anchors. Moreover, anchors that represent arbitrary 3d poses can be used to represent positions relative to detected or tracked objects when world understanding is expended to include object detection and tracking.
 *   Understanding the semantics of the physical world (such as detecting and tracking markers, images, faces or objects) is outside the scope of this explainer. Currently, there is no specific proposal on how to expose even basic understanding of the physical world to the web, much less more interesting objects. Whenever such proposal is agreed upon, the scope of the anchor API could evolve to support it. But even in that case, there will still be a need for anchors with arbitrary 3D poses.  Currently, anchors **are not** intended to track moving objects.
 *   Persisting and sharing anchors is outside of the current scope of this explainer, since platform-level anchors (used to implement the anchor concept) are opaque and not compatible across different platforms.
 
-Anchors are intended to maintain a pose that corresponds to a location in the physical world, and will be updated by the system as the it's understanding of the physical-world changes. 
+Anchors are intended to maintain a pose that corresponds to a location in the physical world, and will be updated by the system as it's understanding of the physical-world changes. 
 
 # Use Cases
 
 In general, applications should use anchors whenever a virtual object is placed in the scene. This is the only way to ensure the pose of the virtual object will be continuously updated to maintain a fixed relationship (i.e., position/orientation) with the physical world over time.
 
 There are different strategies an application may use to create anchors, depending on its particular scene graph structure, but as a general use case, any virtual object that will be positioned in world space should be positioned relative to an anchor. In some cases, a single anchor might serve as the base coordinate system for multiple objects, such as when an app places a complex scene composed of multiple elements somewhere in the physical world. Only one anchor is needed in this case, as all of the elements are relative to the same phyisical location.
 
-Imagine a small race track with cars on it. The race track will be placed at a location world space, so an anchor should be created for it, but  the cars are positioned relative to the race track, and the whole race track should move together if the anchor is repositioned. A pose update for the race track's anchor will, in turn, update the cars on top of it.
+Imagine a small race track with cars on it. The race track will be placed at a location world space, so an anchor should be created for it, with  the cars positioned relative to the race track. A pose update for the race track's anchor will update the location of the race track and, in turn, the location of the cars position relative to it.
 
 If the race track is very large, and has been laid out interactively by the user pointing at locations in the world, multiple anchors might be used for each of these locations.  In this case, an application might need to adjust the exact model of the track over time, as anchors might shift relative to each other as the user moves around the exact locations of the anchors change.  Such a scenario is more complex, but will ensure that different parts of the track are anchored to the locations the user specified, despite the system's understanding of the world evolving.
 
-Although most use cases for anchor creation might be related to real-world understanding (e.g., placing the virtual race track on top of a real table), there are also use cases where anchors are created based on an arbitrary pose relative to the user's head (i.e., the system camera), instead of a direct relationship to the physical world. Imagine placing a virtual HUD (Heads Up Display) in mid air in front of the user to access a quick menu in AR. The placement of the UI element could be at some specific comfortable distance in front of the user, and an anchor would be needed to make sure the UI stays at the correct position/orientation even if the world coordinates change while the menu is visible.
+Although most use cases for anchor creation might be related to real-world understanding (e.g., placing the virtual race track on top of a real table), there are also use cases where anchors are created based on an arbitrary pose relative to the user's head (i.e., the system camera), instead of a direct relationship to the physical world. Imagine placing a virtual HUD (Heads Up Display) in mid air in front of the user to access a quick menu in AR. The placement of the UI element could be at some specific comfortable distance in front of the user, and an anchor should be used to make sure the UI stays at the correct position/orientation even if the world coordinates change while the menu is visible.
 
 Two examples where Anchors might update as real-world understanding improves are:
 
-1.  The system gains a more precise understanding of where a physical object is, which affects the pose created relative to it. For example, if a pose was created relative to a plane perceived at 1m above the floor, and as the user moves around, the system refines this estimateto being 0.95m above the floor, then the Anchor pose will be updated;
-1.  The system shift the world coordinate system used to specify the camera location. For example, if a pose was created (relative to the physical world, or to the camera) such that the world position is (1,1,1), and the system subsequently shifts it's world coordiantes such that the position that was formerly (1,1,1) is now (0.75,1,1), then the Anchor pose can updated accordingly.
+1.  The system gains a more precise understanding of where a physical object is, which affects the pose created relative to it. For example, if a pose was created relative to a plane perceived at 1m above the floor, and as the user moves around the system refines this estimate to being 0.95m above the floor, then the Anchor pose will be updated;
+1.  The system shifts the world coordinate system used to specify the camera location. For example, if a pose was created (relative to the physical world, or to the camera) such that the world position is (1,1,1), and the system subsequently shifts it's world coordiantes such that the position that was formerly (1,1,1) is now (0.75,1,1), then the Anchor pose must be updated accordingly.
 
 
 # Possible API Considerations
@@ -104,7 +106,7 @@ partial interface XRSession {
 
 ## Code examples
 
-The following code examples try to clarify the proposed IDL API. They use ThreeJS to simplify some concepts representing the virtual objects/models.
+The following code examplesa try to clarify the proposed IDL API. They use ThreeJS to simplify some concepts representing the virtual objects/models.
 
 ### Adding anchors