@vertigis/viewer-spec 50.5.0 → 50.6.0

package/docs/layout-spec.md

@@ -5,28 +5,27 @@
 A Microsoft Word version of this document is maintained in the Products Team SharePoint site.
 This document should be treated as the source of the Word document.
 
-
 ## Amendments
 
 As per the March 17, 2017 meeting, the following modifications were decided upon:
 
-- Config items referenced from layout should support an additional short hand notation where the item type is not specified. Instead, since the item type for the particular component is already known, we can use that in conjunction with a supplied item id, to find the item on the app.json. Example: <map id="secondary" config="ortho-photos-2017" />
+-   Config items referenced from layout should support an additional short hand notation where the item type is not specified. Instead, since the item type for the particular component is already known, we can use that in conjunction with a supplied item id, to find the item on the app.json. Example: <map id="secondary" config="ortho-photos-2017" />
 
 The URI based syntax is also supported. Example:
 
 <map id="secondary" config="item://MapExtension/ortho-photos-2017" />
 
-- We won’t be building shell components until we need them, if we need them. Additionally, the term "shell" may or may not be used.
-
-- The term "group" is preferable and more clear than "region".
+-   We won’t be building shell components until we need them, if we need them. Additionally, the term "shell" may or may not be used.
 
-- Regions/groups will not be implemented until we need them, if we need them.
+-   The term "group" is preferable and more clear than "region".
 
-- CSS style selectors for targeting components were using a dot (.) in front of component types. The dot should be dropped to be in alignment with CSS.
+-   Regions/groups will not be implemented until we need them, if we need them.
 
+-   CSS style selectors for targeting components were using a dot (.) in front of component types. The dot should be dropped to be in alignment with CSS.
 
 ## Intro
-The new _Geocortex API_ introduces a powerful new schema for defining and managing spatial applications.
+
+The _ArcGIS Extensions API_ introduces a powerful schema for defining and managing spatial applications.
 
 This schema is used by our next-generation _viewers_, and represents the ability to express fully cross-platform _apps_ via singular, shareable items. For example, an _inspections.json_ app in your organization's Portal that defines all of the configuration involved in realizing a running instance of that particular application.
 
@@ -36,8 +35,8 @@ In order to achieve the objective of truly cross-platform apps, and to account f
 
 This new entity is known as an _Application Layout_, and is a resource that can be referenced by apps or inferred from a simple Web Map. This new entry into our lexicon represents a design language capable of rapidly expressing simple and complex apps alike, and in terms of reusable, contextually bound components.
 
-
 ## Overview
+
 Application Layouts are simple, human readable XML documents. They express the _structural composition_ and _visual arrangement_ of apps in terms of their constituent components, and how those components interact with each other.
 
 **Layouts are strictly technology neutral**. As a hard rule, implementation details from _specific technologies_ should never leak into layouts, just like they should never leak into the API.
@@ -49,56 +48,60 @@ Apps reference one more _layouts_ as _items_. When a viewer loads an app, it "se
 The details of how a viewer selects the appropriate layout to load on app startup is left out of this document and can safely be considered a viewer-level implementation detail. However, it's worth noting that layouts can be hardcoded or synthesized as well. For example, a viewer may derive a layout directly from a Web Map when loading an app that references no layouts, or simply fall back to a map centric, in-built default.
 
 ### Notes
-- Layouts are concise, technology-agnostic XML documents
-- Layouts define user interfaces in simple, cross-platform ways
-- Layouts bind user interface elements to configured items
-- Layouts are no different than any other item an app can reference
-- Apps can reference multiple layouts, in which case a viewer will select the one to load
-- Layouts can be derived from Web Maps or Web Scenes when none is available
 
+-   Layouts are concise, technology-agnostic XML documents
+-   Layouts define user interfaces in simple, cross-platform ways
+-   Layouts bind user interface elements to configured items
+-   Layouts are no different than any other item an app can reference
+-   Apps can reference multiple layouts, in which case a viewer will select the one to load
+-   Layouts can be derived from Web Maps or Web Scenes when none is available
 
 ## Proposed Schema Versions
+
 In contrasting GMV and GWV requirements and objectives as well as potential enhancements, we have decided to consider multiple layout spec versions:
 
 1.0: A scope-constrained 1.0 suitable for initial versions of GMV to use.
 1.1: Introduces support for multiple components, and mechanisms for working with "arity"
 1.2: A set of progressive enhancements that possibly includes accessibility mechanisms (e.g. skip lists), control over fault-tolerance, support for printing, and support for drag and drop
 
-This document covers the core aspects of 1.0 and 1.1. GMV will initially use spec 1.0, and GWV will use 1.1 to allow more flexible layouts. 
+This document covers the core aspects of 1.0 and 1.1. GMV will initially use spec 1.0, and GWV will use 1.1 to allow more flexible layouts.
 Each version of the spec will have an XSD.
 
-
 ### Schema 1.0
+
 Version 1.0 addresses ground-level compatibility topics between viewers, primarily by defining and normalizing patterns and practices that may have implications that affect compatibility across viewers.
 
 #### 1.0 Topics:
-- App compatibility across GWV and GMV
-- Syntax and semantics
-- Binding of configuration to components
-- Lazy loading and baseline fault tolerance for components
-- Core set of initial components (i.e. `map`, `scene`, "primitives")
-- Technology-neutral, resolution-independent sizing and positioning attributes (a.k.a. "liquid layouts")
 
+-   App compatibility across GWV and GMV
+-   Syntax and semantics
+-   Binding of configuration to components
+-   Lazy loading and baseline fault tolerance for components
+-   Core set of initial components (i.e. `map`, `scene`, "primitives")
+-   Technology-neutral, resolution-independent sizing and positioning attributes (a.k.a. "liquid layouts")
 
 ### Schema 1.1
+
 Version 1.1 addresses secondary concerns and value additions that GMV 1.0 can safely defer.
 GWV has already implemented "arity", and accessibility (WCAG 2.0 AA) is required for GVH parity.
 Because of this, GWV should ship with schema 1.1.
 
 #### Topics:
-- Declarative control over "arity" (i.e. handling 0-to-many maps, scenes, etc)
-- Accessibility enhancements, i.e. skip lists, declarative screen reader content and controls
 
+-   Declarative control over "arity" (i.e. handling 0-to-many maps, scenes, etc)
+-   Accessibility enhancements, i.e. skip lists, declarative screen reader content and controls
 
 ### Schema 1.2
+
 Schema 1.2 extends previous versions
 
 #### Topics:
-- Declarative control over fault tolerance (e.g. "failure mode" attributes)
-- Non-interactive use cases (i.e. relationships to _Print Templates_, _Reports_)
 
+-   Declarative control over fault tolerance (e.g. "failure mode" attributes)
+-   Non-interactive use cases (i.e. relationships to _Print Templates_, _Reports_)
 
 ## Syntax and semantics
+
 Layouts use simple XML to represent user interfaces with as little cognitive load as possible.
 Here is a layout expressing a simple spatial application comprised of a map:
 
@@ -130,7 +133,7 @@ In this example, the custom namespace for Cityworks is added to a layout documen
 
 We recognize that admins and implementors frequently hand-edit configuration, and thus consider it a part of UX. With this in mind, our syntax and semantics are intended to be concise and human-friendly. Like apps, layouts are always _human readable_, and suitable for _hand-editing_.
 
-In layouts, element and attribute names are "kebab-cased". Words are always lowercase and seperated by hyphens:
+In layouts, element and attribute names are "kebab-cased". Words are always lowercase and separated by hyphens:
 
 ```XML
 <map>
@@ -141,16 +144,17 @@ In layouts, element and attribute names are "kebab-cased". Words are always lowe
 Double-quotes are used for attributes, and we suggest that attribute values use the same kebab-cased convention.
 
 # Notes
-- Layouts are human-friendly, expressed in simple, concise XML
-- Layouts can include custom components via XML namespaces
-- Layout elements and attribute names are "kebab-cased":
-    - All lowercase
-    - Words separated by hyphens, i.e. `<my-custom-component spin-map="true" />`
-- Double-quotes are used for attributes
-- Kebab-casing suggested for attribute values as well
 
+-   Layouts are human-friendly, expressed in simple, concise XML
+-   Layouts can include custom components via XML namespaces
+-   Layout elements and attribute names are "kebab-cased":
+    -   All lowercase
+    -   Words separated by hyphens, i.e. `<my-custom-component spin-map="true" />`
+-   Double-quotes are used for attributes
+-   Kebab-casing suggested for attribute values as well
 
 ## Layouts bind components to config
+
 As a viewer loads a layout, it maps components to configuration items in an _app container_, resolving them asynchronously and passing them to the components for consumption during initialization.
 
 These bindings to config are known as "item references", and they can be explicit or implicit. Example:
@@ -174,20 +178,20 @@ When the viewer finds a map component with no item reference specified, it can u
 
     item://Map/default
 
-
 ## Missing configuration
+
 When a component implicitly or explicitly references config that does not exist in the app, the component is said to have _missing config_.
 This type of fault is not treated as _exceptional_. Depending on use case, it may be A-OK to simply hide components who have missing config.
 
 For any component encountered that is found to have _missing config_, a viewer may choose to do one of the following:
-    A. Halt the loading process, indicating to the user that a component is missing configuration and the app failed to load
-    B. Issue a warning to the user, continuing the loading process, ignoring any subcomponents configured under the failed one
+A. Halt the loading process, indicating to the user that a component is missing configuration and the app failed to load
+B. Issue a warning to the user, continuing the loading process, ignoring any sub-components configured under the failed one
 
 Which option a viewer takes for a given component is referred to as the component's _failure mode_, and declarative control over this is deferred as a possible 1.2 topic.
 
-
 ## Unresolved configuration
-When a component has an explicit or implict item reference, but that item reference fails to load, it is considered as having _unresolved configuration_.
+
+When a component has an explicit or implicit item reference, but that item reference fails to load, it is considered as having _unresolved configuration_.
 Unlike _missing config_, this class of fault is exceptional - it indicates an erroneous situation.
 Something has caught on fire, or the user does not have access.
 
@@ -200,15 +204,16 @@ C) Malformed configuration
 As a viewer loads a layout, instances of unresolved config (and for why they are unresolved) are collected for the purposes of presenting a user a singular prompt for which to acknowledge the errors, and/or retry an authentication flow.
 
 As is the case with _missing config_, a viewer that loads components with _unresolved config_ can continue loading if and when components fail to load unresolved config.
-However, since unresolved configuration represents exceptional (erroneous) behaviour, the user should receive notification of the fault(s). 
-
+However, since unresolved configuration represents exceptional (erroneous) behavior, the user should receive notification of the fault(s).
 
 ## Loading sequence
+
 This layout consists of a single web map and for which a _binding to the default `MapExtension` in the app is implied:_
 
 ```XML
 <map />
 ```
+
 Upon encountering a component bearing no item reference, a viewer will:
 
 1. Check the component's metadata for a "default item type"
@@ -217,9 +222,9 @@ Upon encountering a component bearing no item reference, a viewer will:
 1. If the item does not exist in the container, the viewer will consider the component as having _missing config_
 1. If the item exists in the container, but cannot be resolved to due auth or service failure, it is considered to have _unresolved config_
 1. When a component has _missing_ or _unresolved_ config, the viewer may choose to do one of the following:
-    A. Halt the loading process, indicating to the user that a component is missing configuration and the app failed to load
-    B. Fallback to "baked in" configuration for the component, colocated with the module, entering a mode of "outright failure", or option C
-    C. Logging a warning, and continuing the loading process, ignoring any subcomponents configured under the failed one
+   A. Halt the loading process, indicating to the user that a component is missing configuration and the app failed to load
+   B. Fallback to "baked in" configuration for the component, colocated with the module, entering a mode of "outright failure", or option C
+   C. Logging a warning, and continuing the loading process, ignoring any sub-components configured under the failed one
 
     Which option is chosen is considered a component's _failure mode_.
 
@@ -228,7 +233,7 @@ Future schema versions may wish to treat these faults differently.
 
 Missing config simply means that the contents of the layout and the app don't necessarily line up, and that is OK in certain use cases.
 Debug warnings can be logged, but the viewer may not wish to expose any "failure" to the average user.
-This means that we can use any layout with any app, and simply gracefully degrade. In other words, a viewer's default layout is capable of loading *any*
+This means that we can use any layout with any app, and simply gracefully degrade. In other words, a viewer's default layout is capable of loading _any_
 app without outright failure. The user simply won't see components that are missing config.
 
 Contrast this to _unresolved_ config, where we are either not authorized, or a Portal is broken or has moved, or we have encountered outright broken configuration.
@@ -237,14 +242,14 @@ For this class of failure, we will most likely want to at least notify the user
 **Note:** For GMV 1.0 and GWV 1.0, we suggest a default "failure mode" of "continue loading whatever else you can, logging warnings to the console".
 Declarative control of this is proposed as a future topic for Schema 1.2.
 
-
 ### Summary
-- When an item reference and a _defaults.json_ are not available, the viewer will simply warn the user and continue loading
-- This "baseline" of fault tolerance may be controlled by admins and devs in the future, i.e. to explicitly fail on missing config
-- For 1.0, the viewer will just continue loading and emit useful log information saying that component X or Y could not be loaded to to missing config
 
+-   When an item reference and a _defaults.json_ are not available, the viewer will simply warn the user and continue loading
+-   This "baseline" of fault tolerance may be controlled by admins and developers in the future, i.e. to explicitly fail on missing config
+-   For 1.0, the viewer will just continue loading and emit useful log information saying that component X or Y could not be loaded to to missing config
 
 ## Composition: Slotting
+
 Consider the following example layout:
 
 ```XML
@@ -258,7 +263,7 @@ How might a user anchor the scale bar component to a particular corner or edge o
 
 To phrase in more technical terms: how are components _composed_ together? The answer to this question is "slotting".
 
-> Note: The behaviour and terminology for "slotting" is borrowed from the _Web Components_ spec, where the major browser vendors have collectively solved and defined the problems and solutions to composing elements hierarchically.
+> Note: The behavior and terminology for "slotting" is borrowed from the _Web Components_ spec, where the major browser vendors have collectively solved and defined the problems and solutions to composing elements hierarchically.
 
 _Slotting_ is the act of hosting components inside of other components, and involves a declarative mechanism for layout authors to target "slots" when composing components together.
 
@@ -271,9 +276,9 @@ To anchor to the top right corner, a layout author may express the following:
 </map>
 ```
 
-> Note: The behaviour described below is currently specific to GWV.
-When the layout loader encounters the scale bar, it will recognize the "slot" attribute, defined in our Geocortex namespace.
-When it goes to "slot" the scale bar into the map, it will make a "slotting request" to the map component, passing it some information about the child component as well as the intended slot target.
+> Note: The behavior described below is currently specific to GWV.
+> When the layout loader encounters the scale bar, it will recognize the "slot" attribute, defined in our Geocortex namespace.
+> When it goes to "slot" the scale bar into the map, it will make a "slotting request" to the map component, passing it some information about the child component as well as the intended slot target.
 
 The map component may "accept" or "reject" the slotting request. If it accepts, it will place the child component in the correct position in its own DOM in order to satisfy the slotting request.
 
@@ -283,8 +288,8 @@ The notion of a slotting "request" is realized as nothing more than a simple met
 
 > Note: While this mechanism is dirt-simple, formalizing it helps conceptually enable potential support for drag-and-drop app creation down the road.
 
-
 ### Implicit slots
+
 When a slot attribute is present, this is known as _named slotting_ or _explicit slotting_.
 When no slot attribute is present, this is known as _implicit slotting_.
 
@@ -303,14 +308,15 @@ As with named slotting, components can reject implicit slotting.
 
 Here, the map may choose to reject the slotting request, since it only has named slots: the four corners of the map where content can be anchored.
 
-However, a component with no implicit slot behaviour is free to satisfy a request for implicit slotting by simply slotting it into a default slot of its choosing, i.e. "bottom-left".
+However, a component with no implicit slot behavior is free to satisfy a request for implicit slotting by simply slotting it into a default slot of its choosing, i.e. "bottom-left".
 This is a component-specific implementation detail.
 
-By supporting the simple compositional stategy of "slotting", we provide layout authors simple yet powerful tools for declaratively building simple and sophisticated apps alike, and entirely out of loosely-coupled, reusable components.
-
+By supporting the simple compositional strategy of "slotting", we provide layout authors simple yet powerful tools for declaratively building simple and sophisticated apps alike, and entirely out of loosely-coupled, reusable components.
 
 ### Slotting examples
+
 Scale Bar and Overview Map explicitly slotted:
+
 ```XML
 <map>
     <scale-bar slot="bottom-left" />
@@ -319,6 +325,7 @@ Scale Bar and Overview Map explicitly slotted:
 ```
 
 A stack of implicitly slotted maps:
+
 ```XML
 <stack>
     <map />
@@ -328,14 +335,16 @@ A stack of implicitly slotted maps:
 ```
 
 2.x style "hoisting" into a panel's slot:
+
 ```XML
 <smart-panel id="data-frame">
     <menu slot="hoist" config="item://Menu/results-list" />
     <results-list />
-</smart-panel> 
+</smart-panel>
 ```
 
 Slotting into a "master detail page" component
+
 ```XML
 <mdp>
     <menu config="item://Menu/master" slot="master" />
@@ -344,6 +353,7 @@ Slotting into a "master detail page" component
 ```
 
 Slotting into a traditional "shell" component:
+
 ```XML
 <mobile-shell>
     <menu config="item://Menu/nav-mobile-main" slot="primary-menu" />
@@ -355,25 +365,26 @@ Slotting into a traditional "shell" component:
 ```
 
 ### Summary
-- When components are nested in other components in layouts, they are "slotted" into them
-- When a component attempts to slot into another, the layout loader asks the host component to satisfy the slotting
-- Host components can accept or reject slotting attempts (*Note:* currently GWV specific)
-- When a slotting request fails during load, the slotee enters a failure state
-- When a child component bears a "slot" attribute, it targets a "named slot" in its parent
-- When a child component bears no "slot" attribute, it targets the "implicit slot" in its parent
 
+-   When components are nested in other components in layouts, they are "slotted" into them
+-   When a component attempts to slot into another, the layout loader asks the host component to satisfy the slotting
+-   Host components can accept or reject slotting attempts (_Note:_ currently GWV specific)
+-   When a slotting request fails during load, the slotee enters a failure state
+-   When a child component bears a "slot" attribute, it targets a "named slot" in its parent
+-   When a child component bears no "slot" attribute, it targets the "implicit slot" in its parent
 
 ## A note about "shells"
+
 Shells have been a winning pattern for us, particularly in the realm of GVH, where we can target wildly different form factors with specific arrangements of components and navigational structures.
 
-In the new "layout era", the role of shells is a bit diminished. It is layouts themselves that define the visual arrangement of components, as well as the compositional behaviour between them.
+In the new "layout era", the role of shells is a bit diminished. It is layouts themselves that define the visual arrangement of components, as well as the compositional behavior between them.
 
 However, this is not to say that shells are obsolete. Sometimes, we need to address high-level UI concerns that aren't suitable for individual components to address themselves. For example, a complex interplay between config, a "home panel", and a "data frame" is best expressed specifically in a higher level component rather than polluting the constituents with specific application-level concerns.
 
 Shells are not obsolete. Shells are just high-level components comprised of other components!
 
-
 ## A note about "views"
+
 If components can implicitly host other components by default, and components can be parked inside other components via nominal "slots", it raises the following question:
 
 What happens to regions and views?
@@ -382,11 +393,11 @@ In a nutshell: The term "view" now references the specific user interface of a c
 
 A view is a specific component's interface, realized using platform-specific UI controls and components.
 
-
 ## Regions
+
 Regions evolve a bit with the introduction of layouts, but are perhaps even more useful than before.
 
-In GVH, regions are nominal targets for views. In 2.x configs, user interfaces are expressed as flattened graphs, with views targetting regions by globally unique names and forming "edges" in the flattened graph.
+In GVH, regions are nominal targets for views. In 2.x configs, user interfaces are expressed as flattened graphs, with views targeting regions by globally unique names and forming "edges" in the flattened graph.
 
 In the new hierarchical paradigm, regions serve as simple grouping constructs, as well as continuing to serve as nominal targets for commands and workflows. However, unlike GVH 2.x, regions are not defined in view templates: they are only defined in layouts.
 
@@ -432,15 +443,16 @@ A less contrived example would be grouping components so that they may be treate
 While there are similarities between regions and slots, they are distinct because they serve different purposes for different audiences: Regions are defined by layout authors for naming groups of components, while slots are defined by developers as composition targets in views.
 
 ### Summary
-- Regions are defined in layouts
-- Slots are defined in views
-- Regions are useful grouping constructs
 
+-   Regions are defined in layouts
+-   Slots are defined in views
+-   Regions are useful grouping constructs
 
 ## Dispatch: Commands
+
 > Note: Dispatch is spec 1.1
 
-Because our configuration and composition models support 0-to-many of any component, application authors need a way of specifying the targets of particlar commands and event invocations. How messages such as commands and events are delivered to the correct recipients is known as "dispatch".
+Because our configuration and composition models support 0-to-many of any component, application authors need a way of specifying the targets of particular commands and event invocations. How messages such as commands and events are delivered to the correct recipients is known as "dispatch".
 
 Consider this example:
 
@@ -464,11 +476,12 @@ Unlike a structural mechanism like XPath (which was considered) our syntax speci
 
 Since items in apps such as menus and toolbars may bear dispatch config, the nominal approach ensures that they aren't bound to the structure of any particular layout. For example, a configured menu item that zooms a particular map by name will function as intended no matter where in the app that map (should it exist) is hosted. This prevents app configs from becoming "brittle" and coupled to particular layouts.
 
-
 ### Binding syntax
+
 Binding syntax allows authors to target components by referencing components by ID or type.
 
 ### Nominal binding
+
 Components can be referenced by ID using the "#" character:
 
 ```XML
@@ -476,11 +489,13 @@ Components can be referenced by ID using the "#" character:
 ```
 
 Multiple binding expressions (of any type) are allowed. Commas are used to separate bindings:
+
 ```XML
 <button cmd="zoom-in" targets"#map1, #map2">I zoom maps</button>
 ```
 
 ### Type binding
+
 Components of a particular type can be target using the "." character:
 
 ```XML
@@ -490,8 +505,7 @@ Components of a particular type can be target using the "." character:
 
 ### Attribute matching
 
-> Note: Spec version 1.2 
-
+> Note: Spec version 1.2
 
 Bindings can specify simple key-value patterns to match arbitrary attributes on component:
 
@@ -509,10 +523,9 @@ Attribute matching can apply to all components of any type as well, simply by om
 <button cmd="zoom-in" targets="[role=navigation]">I target any component marked with role=navigation</button>
 ```
 
-
 ## Model bindings
-> Note: Spec version 1.1
 
+> Note: Spec version 1.1
 
 Components often observe and modify the state of other components.
 Consider the following example:
@@ -622,7 +635,7 @@ This allows the layout author to specify the "#map" hint on a parent component,
         <map id="map" />
     </region>
 </split>
-``` 
+```
 
 This is known as "model pinning". We've "pinned" any exported models from the map to the panel for its children to consume.
 Note that the panel component itself remains wholly uncoupled from any map concerns - it is simply decorated in this particular layout in order to keep the layout clean and concise.
@@ -639,10 +652,9 @@ In this case, the layout author can specify their binding as a binding to multip
 It's worth noting that this strategy of contextually resolving model dependencies between components lends itself extremely well to a potential drag and drop implementation.
 When components are "dropped" into new locations, we can simply re-slot them and re-resolve their model dependencies.
 
-
 ## Presentation
-> Note: Originally out of scope for 1.0, but required by GMV to express basic UI structure.
 
+> Note: Originally out of scope for 1.0, but required by GMV to express basic UI structure.
 
 Layouts can bear attributes related to visual presentation such as widths, heights, margins, and paddings.
 These attributes are applied on components to control their presentation in the layout.
@@ -665,8 +677,8 @@ Consider this example:
 In this case, there are 10 units of space available. The first map has 10% of them, while the second has 90%.
 This particular layout can be understand to have a map that's 10% the height of the available space, and a second map that takes up the other 90%.
 
-
 ## Internationalization
+
 In order to support localized apps, layouts must be able to reference localized strings. A simple method is proposed:
 
 ```XML
@@ -682,30 +694,29 @@ By avoiding absolute coordinates, we create easy solutions for RTL, which is typ
 
 > Note: RTL is a 1.2 topic
 
-
 ## Common components
+
 As part of the layout specification, a common set of components for both viewer should be defined.
 Viewer specific components can live in viewer-specific namespaces, and components that we decide to make common can be elevated into the common namespace.
 
 The common set of components we have defined so far are:
 
-  - stack
-  - split
-  - text
-  - dialog
-  - panel
-  - button
-  - map
-  - scene
+-   stack
+-   split
+-   text
+-   dialog
+-   panel
+-   button
+-   map
+-   scene
 
 Aside from map and scene, these components are considered "primitives": simple building blocks for layouts that are easy to implement and suitable for us to begin exploring and experimenting with application interfaces.
 
 Along with simple presentation attributes such as width and height, stack and split components give us trivially simply blocks that can form the basis for almost any user interface. Stack simply vertically stacks components, while split horizontally partitions screen real estate, flipping the order of components for RTL. Both stacks and splits can allow their child components to be resized.
 
-Dialogs handle popup behaviour, and panels can provide functionality similar to "smart panels" today: accessible containers for content, and with panel-specific menu actions.
-
-The text component is similar in nature to our Markdown form item, and can show arbitrary blocks of rich content including images, and possibly command hyperlinks and substituted tokens, similiar to our _Home Panel_ and _Feature Description_ functionality.
+Dialogs handle popup behavior, and panels can provide functionality similar to "smart panels" today: accessible containers for content, and with panel-specific menu actions.
 
+The text component is similar in nature to our Markdown form item, and can show arbitrary blocks of rich content including images, and possibly command hyperlinks and substituted tokens, similar to our _Home Panel_ and _Feature Description_ functionality.
 
 ## Summary
 

package/layout/schema/layout-common.xsd

@@ -90,7 +90,7 @@
         <attribute name="config" type="string">
             <annotation>
                 <documentation xml:lang="en">
-                    The ID of a corresponding item in a Geocortex App that
+                    The ID of a corresponding item in a VertiGIS Studio App that
                     contains this component's configuration and state.
                 </documentation>
             </annotation>

package/layout/schema/layout-web.xsd

@@ -105,7 +105,7 @@
     <element name="inline" substitutionGroup="base:component">
         <annotation>
             <documentation xml:lang="en">
-                A component that allows the integration of Geocortex Inline (Deprecated).
+                A component that allows the integration of VertiGIS Studio Inline (Deprecated).
             </documentation>
         </annotation>
         <complexType>

package/messaging/Command.d.ts

@@ -23,7 +23,8 @@ export interface Command<T = void> extends Message {
      * Executes the command.
      *
      * @param argument The command arguments.
-     * @param options CancelToken or options to apply to the commands execute behavior.
+     * @param options CancelToken or options to apply to the commands execute
+     *   behavior.
      */
     execute(argument: T, options?: CancelToken | MessageExecuteOptions): Promise<void>;
     /**
@@ -61,7 +62,8 @@ export interface CommandContext<T> extends AnalyticsContext {
      * Invokes the next behavior in the chain. If it isn't invoked explicitly,
      * then the next behavior will run after the current one is finished. Note
      * that this is not supported for behaviors that are added at runtime via
-     * registerParallel(), which have no explicit sequence as they are run concurrently.
+     * registerParallel(), which have no explicit sequence as they are run
+     * concurrently.
      */
     next: (argument?: T) => Promise<void>;
     /**

package/messaging/Event.d.ts

@@ -10,13 +10,15 @@ export interface Event<T = void> extends Message {
     /**
      * Publishes the event to all subscribers.
      *
-     * @returns A promise that is fulfilled once all subscribers have been notified.
+     * @returns A promise that is fulfilled once all subscribers have been
+     *   notified.
      */
     publish: (arg: T) => Promise<void>;
     /**
      * Subscribes to this event.
      *
-     * @param callback A callback that will be invoked whenever the event is published.
+     * @param callback A callback that will be invoked whenever the event is
+     *   published.
      * @returns A handle that can be used to unsubscribe.
      */
     subscribe: (callback: EventCallback<T>) => IHandle;

package/messaging/Message.d.ts

@@ -23,7 +23,8 @@ export interface MessageExecuteOptions {
     /**
      * The XML name of the layout component that initiated the action, if
      * applicable. This will be available in the command context and can be used
-     * by message handlers for capturing analytics. Examples: "layer-list", "map", etc.
+     * by message handlers for capturing analytics. Examples: "layer-list",
+     * "map", etc.
      */
     analyticsComponentType?: string;
     /**

package/messaging/Operation.d.ts

@@ -24,7 +24,8 @@ export interface Operation<T = void, TResult = undefined> extends Message {
      * Executes the operation and returns its result.
      *
      * @param argument The argument to the operation.
-     * @param options CancelToken or options to apply to the Operation execute behavior.
+     * @param options CancelToken or options to apply to the Operation execute
+     *   behavior.
      */
     execute: (argument: T, options?: CancelToken | MessageExecuteOptions) => Promise<TResult>;
     /**
@@ -36,7 +37,8 @@ export interface Operation<T = void, TResult = undefined> extends Message {
     /**
      * Initializes the operation if it is not already initialized. Attempting to
      * execute an operation will automatically initialize it, however calling
-     * canExecute() will always return false until the operation is initialized.
+     * canExecute() will always return false until the operation is
+     * initialized.
      */
     initialize(): Promise<void>;
 }