chore: update component requirements in schemas

Author: mwfarb

content/3d-content/gltf-files.md

@@ -17,11 +17,11 @@ scene.bin  scene.gltf  textures
 
 ## SketchUp
 Getting from [SketchUp](https://www.sketchup.com/) to GLTF is a bit of an adventure:
-- The online converters don’t generate valid GLTFs.
+- The online converters don't generate valid GLTFs.
 - The SketchUp GLTF export plugin was written for SketchUp 2016 and seems to hang SketchUp 2020 — these models were created in SketchUp 2017, so the 2016 version refuses to open them.
 - What worked was installing Adobe Dimension, opening the SketchUp file there, and exporting it.
 
-Dimension doesn’t seem to edit these models well, so if you want to patch up some textures, it's recommended to do that in SketchUp first, then saving a copy, using Dimension to convert to GLTF.
+Dimension doesn't seem to edit these models well, so if you want to patch up some textures, it's recommended to do that in SketchUp first, then saving a copy, using Dimension to convert to GLTF.
 
 ## Adobe Dimension
 For [Adobe Dimension](https://www.adobe.com/products/dimension.html), the general conversion steps are:

content/3d-content/matterport.md

@@ -6,7 +6,7 @@ parent: 3D Content
 
 # Scanning a Large Space with Matterport
 For higher fidelity models, we use the [Leica BLK360](https://shop.leica-geosystems.com/leica-blk/blk360/product-details), a terrestrial laser scanner (TLS) with registered 360 color images.
-Using the BLK360, along with 3D reconstruction software (e.g. Leica’s [Cyclone FIELD 360](https://leica-geosystems.com/en-us/products/laser-scanners/software/leica-cyclone/leica-cyclone-field-360), or [Matterport](https://matterport.com)), we create 3D models of physical spaces that can easily be imported into ARENA.
+Using the BLK360, along with 3D reconstruction software (e.g. Leica's [Cyclone FIELD 360](https://leica-geosystems.com/en-us/products/laser-scanners/software/leica-cyclone/leica-cyclone-field-360), or [Matterport](https://matterport.com)), we create 3D models of physical spaces that can easily be imported into ARENA.
 
 {% include alert type="info" title="$$$" content="Be sure to check the software pricing model, since these software packages may charge you to retrieve the final GLTF." %}
 

content/architecture/anchoring.md

@@ -9,7 +9,7 @@ parent: Architecture
 
 ARENA provides several mechanisms to help streamline the management and sharing of anchor data as well as simplifying the process of combining multiple tracking technologies into a uniform coordinate system.
 
-ARENA scenes can be registered and discovered by the **Atlas service**. Atlas is an essential ARENA service that allows users to find nearby content based on coarse location and supports managing the data needed to link Scene content with the physical world. Atlas operates in a hierarchical manner much like the Internet’s Domain Name Service (DNS), but using a mixture of GPS coordinates, UUIDs and Scenes instead of domain names. UUID markers can be embedded into QR codes,BLE beacons or other digital markers (WiFi, LTE tower, etc). Atlas can also provide absolute and/or local coordinates for markers that are associated with scenes. For example, a user could scan a QR code or read a BLE beacon which provides a UUID that maps to a GPS coordinate along with any Scenes that contain that GPS coordinate. Atlas stores a GPS location for each Scene along with a 3D bounding polygon. The GPS location is typically assigned to the origin of the Scene’s local coordinate system. A user can perform follow-up queries to Atlas for assets that fall within each Scene. For example, a Scene might contain a number of [Apriltags](https://april.eecs.umich.edu/software/apriltag) (low bit-density tracking markers) that have GPS coordinates as well as local coordinates referenced from the Scene’s origin. It is worth noting that a Scene’s address can be used to form a URL for virtual environments that have no physical location.Since Atlas is a public facing entity that needs administrative management, ARENA also supports the ability to store location data within a Scene by attaching real-world properties to objects.
+ARENA scenes can be registered and discovered by the **Atlas service**. Atlas is an essential ARENA service that allows users to find nearby content based on coarse location and supports managing the data needed to link Scene content with the physical world. Atlas operates in a hierarchical manner much like the Internet's Domain Name Service (DNS), but using a mixture of GPS coordinates, UUIDs and Scenes instead of domain names. UUID markers can be embedded into QR codes,BLE beacons or other digital markers (WiFi, LTE tower, etc). Atlas can also provide absolute and/or local coordinates for markers that are associated with scenes. For example, a user could scan a QR code or read a BLE beacon which provides a UUID that maps to a GPS coordinate along with any Scenes that contain that GPS coordinate. Atlas stores a GPS location for each Scene along with a 3D bounding polygon. The GPS location is typically assigned to the origin of the Scene's local coordinate system. A user can perform follow-up queries to Atlas for assets that fall within each Scene. For example, a Scene might contain a number of [Apriltags](https://april.eecs.umich.edu/software/apriltag) (low bit-density tracking markers) that have GPS coordinates as well as local coordinates referenced from the Scene's origin. It is worth noting that a Scene's address can be used to form a URL for virtual environments that have no physical location.Since Atlas is a public facing entity that needs administrative management, ARENA also supports the ability to store location data within a Scene by attaching real-world properties to objects.
 
 ```json
 {
@@ -38,7 +38,7 @@ ARENA scenes can be registered and discovered by the **Atlas service**. Atlas is
 
 **Figure 1**. Example Box Object with an ARMarker.
 
-Figure 1 shows an example of how a box object in a scene can have an AR marker property attached to it. This simplifies the common case where a developer builds a local scene and wants a quick way to manage beacon data annotations for localization systems. ARmarkers can be set as static or dynamic to determine if clients should use them for relocalization or if clients should provide location information for the tag. Our current client can decode AprilTags in browsers that allow camera access (e.g. Mozilla WebXR Viewer and Chrome). If the client decodes a static tag, it uses the location data to compute the pose of the device’s camera. If the tag is dynamic (and the client has a confident fix on its location), it publishes its estimate of the tag location to that object. In this way, multiple users in a space can update and share the location of dynamic tags. Since these tags are attached to objects, this naturally updates the object positions and is reflected across all users and programs. User cameras and rigs can also be updated by external tracking systems.
+Figure 1 shows an example of how a box object in a scene can have an AR marker property attached to it. This simplifies the common case where a developer builds a local scene and wants a quick way to manage beacon data annotations for localization systems. ARmarkers can be set as static or dynamic to determine if clients should use them for relocalization or if clients should provide location information for the tag. Our current client can decode AprilTags in browsers that allow camera access (e.g. Mozilla WebXR Viewer and Chrome). If the client decodes a static tag, it uses the location data to compute the pose of the device's camera. If the tag is dynamic (and the client has a confident fix on its location), it publishes its estimate of the tag location to that object. In this way, multiple users in a space can update and share the location of dynamic tags. Since these tags are attached to objects, this naturally updates the object positions and is reflected across all users and programs. User cameras and rigs can also be updated by external tracking systems.
 
 For example, a Python agent can convert OptiTrack motion capture objects into ARENA position updates. If you target those outputs to specific user cameras or objects, they are automatically localized within the scene. This seamlessly works side-by-side with devices that use optical tags or even UWB localization. We have a number of helper applications that leverage different localization systems to help build tag maps (e.g. OptiTrack can be used to calibrate AprilTags within a shared space). This is another example where the implicitly networked nature of all objects dramatically simplifies merging data from multiple sensing modalities
 

content/architecture/pubsubac.md

@@ -6,11 +6,11 @@ parent: Architecture
 ---
 
 # ARENA PubSub Message Bus
-The ARENA message bus is currently supported by a MQTT Mosquitto broker, modified to keep track of connected clients and data flows. This information is organized into a graph that is available to users and, more importantly, to the [runtime supervisor - ARTS](/content/programs/). The broker is also configured with a [JWT](https://jwt.io/) plugin that implements the PubSub ACL on the topic structure (more details below), and we use Mosquitto’s bridging to create clusters of brokers.
+The ARENA message bus is currently supported by a MQTT Mosquitto broker, modified to keep track of connected clients and data flows. This information is organized into a graph that is available to users and, more importantly, to the [runtime supervisor - ARTS](/content/programs/). The broker is also configured with a [JWT](https://jwt.io/) plugin that implements the PubSub ACL on the topic structure (more details below), and we use Mosquitto's bridging to create clusters of brokers.
 
 ## PubSub Access Control
 
-The root of trust for an ARENA Realm derives from the Access Control List (ACL) permissions managed by the Authentication and Access Control service. Users are authenticated using OAuth and the service emits JSON Web Tokens (JWT) based on permissions for which scenes users control or grant control as an ACL. PubSub brokers and other services (e.g.  the persistence datastore) use JWT to enforce access control. PubSub brokers accept and validate these tokens and use them to allow/disallow publish or subscribe access. We use the PubSub topic structure to sculpt and whitelist which 3D objects, chat, runtime, and other communications bind this ACL to the user’s JWT. To prevent clients from elevating their privileges by publishing malicious messages on the topics they are allowed to publish, we perform client-side checks on message reception and discard invalid messages. See more [security details](/content/architecture/security).
+The root of trust for an ARENA Realm derives from the Access Control List (ACL) permissions managed by the Authentication and Access Control service. Users are authenticated using OAuth and the service emits JSON Web Tokens (JWT) based on permissions for which scenes users control or grant control as an ACL. PubSub brokers and other services (e.g.  the persistence datastore) use JWT to enforce access control. PubSub brokers accept and validate these tokens and use them to allow/disallow publish or subscribe access. We use the PubSub topic structure to sculpt and whitelist which 3D objects, chat, runtime, and other communications bind this ACL to the user's JWT. To prevent clients from elevating their privileges by publishing malicious messages on the topics they are allowed to publish, we perform client-side checks on message reception and discard invalid messages. See more [security details](/content/architecture/security).
 
 A few example topics are included below for context, as well as a list of topic elements used, and which topics are added to the ARENA JWT based upon user and system defined access control list (ACL) settings.
 

content/architecture/runtime.md

@@ -7,7 +7,7 @@ parent: Architecture
 
 ## ARENA Runtime
 
-ARENA applications are compiled into WebAssembly (WASM),an open standard that defines a portable binary code format for executable programs, currently supported by all major web browsers. WASM programs are run in a secure sandbox and have been gaining traction outside of the browser as a lightweight and secure option for serverless-style computing. There are compilers for many languages that target WASM. ARENA includes a WASM runtime environment for browser-capable devices that leverages the already available browser infrastructure, whereas other headless compute elements run a standalone WASM runtime. We are currently developing [WASM runtimes](https://github.com/SilverLineFramework/orchestrator) in both Linux-capable devices and even dispatch Ahead-of-Time (AOT) compiled WASM to microcontrollers. Our WASM runtime accepts requests to execute programs, provides sandboxed execution with access to (also sandboxed) networked resources, and manages the WASM programs’ lifetime, including live migration capabilities (i.e.context swap across devices). The WASM runtime provides a basis for agile programs that operate in the dynamic, distributed computing contexts we imagine for future XR applications. It is an enabler for ARENA applications that can span cloud, edge and device plat-forms in a network transparent manner.  We are also developing a program manager for scenes, we call `init3D`, to provide facilities to manage programs interactively from within scenes.
+ARENA applications are compiled into WebAssembly (WASM),an open standard that defines a portable binary code format for executable programs, currently supported by all major web browsers. WASM programs are run in a secure sandbox and have been gaining traction outside of the browser as a lightweight and secure option for serverless-style computing. There are compilers for many languages that target WASM. ARENA includes a WASM runtime environment for browser-capable devices that leverages the already available browser infrastructure, whereas other headless compute elements run a standalone WASM runtime. We are currently developing [WASM runtimes](https://github.com/SilverLineFramework/orchestrator) in both Linux-capable devices and even dispatch Ahead-of-Time (AOT) compiled WASM to microcontrollers. Our WASM runtime accepts requests to execute programs, provides sandboxed execution with access to (also sandboxed) networked resources, and manages the WASM programs' lifetime, including live migration capabilities (i.e.context swap across devices). The WASM runtime provides a basis for agile programs that operate in the dynamic, distributed computing contexts we imagine for future XR applications. It is an enabler for ARENA applications that can span cloud, edge and device plat-forms in a network transparent manner.  We are also developing a program manager for scenes, we call `init3D`, to provide facilities to manage programs interactively from within scenes.
 
 # ARENA Runtime Orchestrator
 

content/architecture/scenes.md

@@ -7,11 +7,11 @@ parent: Architecture
 
 # ARENA Scenes
 
-ARENA scenes include 3D content, configuration parameters, applications with shared end-points that allow users’ interactions, and information about markers that might serve as location anchors to the Scene. Scenes exist within a tree-like hierarchy with configurable access control and are often attached to a physical location. Using a web analogy, the Realm is like a (local) webserver and the Scene is like a particular web application at a URL endpoint.
+ARENA scenes include 3D content, configuration parameters, applications with shared end-points that allow users' interactions, and information about markers that might serve as location anchors to the Scene. Scenes exist within a tree-like hierarchy with configurable access control and are often attached to a physical location. Using a web analogy, the Realm is like a (local) webserver and the Scene is like a particular web application at a URL endpoint.
 
 ## Scene Objects
 
-ARENA scenes are a collection of <i>Entities</i> to which <i>Components</i> can be attached, following [A-Frame’s Entity-Component-System (ECS) architecture](https://aframe.io/docs/1.5.0/introduction/entity-component-system.html). We support the majority of A-Frames’s primitives (e.g., geometries like boxes, circles, spheres) and components (attributes that can be attached to objects, such as position, rotation, material, sound). We also added ARENA-specific components for AR markers, programs, networked events, and options. All ARENA objects have well-defined JSON schemas, which are the basis for the over-the-wire JSON message format shown below (Figure 2) and are transmitted over the PubSub.
+ARENA scenes are a collection of <i>Entities</i> to which <i>Components</i> can be attached, following [A-Frame's Entity-Component-System (ECS) architecture](https://aframe.io/docs/1.5.0/introduction/entity-component-system.html). We support the majority of A-Frames's primitives (e.g., geometries like boxes, circles, spheres) and components (attributes that can be attached to objects, such as position, rotation, material, sound). We also added ARENA-specific components for AR markers, programs, networked events, and options. All ARENA objects have well-defined JSON schemas, which are the basis for the over-the-wire JSON message format shown below (Figure 2) and are transmitted over the PubSub.
 
 ```json
 {
@@ -40,7 +40,7 @@ ARENA scenes are a collection of <i>Entities</i> to which <i>Components</i> can
 
 **Figure 2**. Example Message and Object Definition.
 
-All messages have an `objectid`, `type`, and an `action` (`create`, `update`, `delete`). Attributes in `data` are the object’s-specific attributes and components. The example shows a box geometry with `depth`, `height` and `width` attributes, `position` and `rotation` components, and an ARENA-specific `ARMarker` component. A [web interface developed to make simple edits to a scene](/content/overview/build), shows an editable scene object list, which can include scene options, programs, lights and 3D geometries and models. We imagine more advanced interfaces could be developed to create scenes, and have already some prototype editors for VR/AR.
+All messages have an `objectid`, `type`, and an `action` (`create`, `update`, `delete`). Attributes in `data` are the object's-specific attributes and components. The example shows a box geometry with `depth`, `height` and `width` attributes, `position` and `rotation` components, and an ARENA-specific `ARMarker` component. A [web interface developed to make simple edits to a scene](/content/overview/build), shows an editable scene object list, which can include scene options, programs, lights and 3D geometries and models. We imagine more advanced interfaces could be developed to create scenes, and have already some prototype editors for VR/AR.
 
 ## Scene Loading
 
@@ -51,7 +51,7 @@ Scenes are loaded akin to web applications within a web browser. However, unlike
 
 ## Real-time Updates
 
-Once loaded, each of the 3D assets in a scene are then updated in real-time over the Realm’s local PubSub bus (see Figure 3). For example, if an application changes the color of a cube, this would be captured in a message over the bus. Figure 4 below exemplifies how a 3D scene is represented.
+Once loaded, each of the 3D assets in a scene are then updated in real-time over the Realm's local PubSub bus (see Figure 3). For example, if an application changes the color of a cube, this would be captured in a message over the bus. Figure 4 below exemplifies how a 3D scene is represented.
 
 ![img](/assets/img/architecture/scene-pubsub.png)