Implement rendering style selection and enhance documentation

README.md

@@ -225,12 +225,15 @@ section above).
 | Multiple views, `--view <name>` | Render only the named view |
 | `--view <name>` names a view that does not exist | Error: lists available view names and exits non-zero |
 
-For the General View diagram strategy (the diagram produced when no more specialized view kind
-applies), a view's body `expose <...>;` statements now scope the rendered diagram to the union of
-the exposed names' containment subtrees, instead of always rendering the full workspace; a view
-with no `expose` statement continues to render the full workspace. `render <target>;` names a
-rendering style (not yet honored) and has no effect on scope. This scoping is not yet extended to
-the other layout strategies — see the *Introduction* user guide for details.
+For every layout strategy (not just the General View), a view's body `expose <...>;` statements
+now scope the rendered diagram to the union of the exposed names' containment subtrees, instead
+of always rendering the full workspace; a view with no `expose` statement continues to render
+the full workspace. `render asTreeDiagram;` and `render asInterconnectionDiagram;` now select
+the Browser View and Interconnection View layout strategies respectively, taking precedence over
+the name/supertype heuristic; other `render` targets (`asElementTable`, `asTextualNotation`, an
+unrecognized name, or none) leave strategy selection unchanged. `render` never affects content
+scope — `expose` remains the sole scoping mechanism regardless of which strategy is selected —
+see the *Introduction* user guide for details.
 
 ## NuGet Packages
 

ROADMAP.md

@@ -95,29 +95,6 @@ new expression-evaluation component; `GeneralViewLayoutStrategy` filter applicat
 **Visual gate:** a view with a `filter [<predicate>];` statement renders only the elements
 satisfying the predicate, with no "not yet evaluated" warning.
 
-### Support selecting rendering style via `render <renderingKind>;`
-
-A view's `render <target>;` member names a rendering style/format usage per the SysML v2
-grammar (e.g. `asTreeDiagram`, `asElementTable`, `asTextualNotation`, `asTextualNotationTable` —
-`rendering` usages, a distinct usage/definition kind) — it is captured verbatim on
-`SysmlViewNode.RenderTargetName` but currently has no effect on rendering; every view renders
-through the single `DiagramTypeRouter` → `ILayoutStrategy` selection regardless of its declared
-`render` member. This is a distinct future capability from content scoping, which is `expose`'s
-exclusive role.
-
-- Design a mapping from recognized rendering-style names (`asTreeDiagram`, `asElementTable`,
-  and so on, once corresponding layout/rendering strategies exist) to an `ILayoutStrategy`/
-  renderer selection, honored when a view declares a `render` member naming one.
-- Leave `RenderTargetName` un-honored (as today) for rendering-style names with no corresponding
-  strategy, with no diagnostic — an unrecognized rendering-style name is not an error, since
-  `render` selects presentation, not content.
-
-**Scope:** `DiagramTypeRouter`/`RenderCommand` (rendering-style selection); new layout/rendering
-strategies for tree-diagram/element-table/textual-notation styles, if not already covered by an
-existing strategy.
-**Visual gate:** a view declaring `render asTreeDiagram;` (once a tree-diagram strategy exists)
-renders using that style instead of the default `GeneralView` layout.
-
 ---
 
 ## Release & packaging

docs/design/introduction.md

@@ -265,7 +265,10 @@ renderer packages have no concept of workspaces or view iteration.
 stdlib-resolved qualified name of a view's viewpoint type (e.g.,
 `SystemsModelingLibrary::Views::GeneralView`), not the raw token. User aliases and
 local imports therefore do not break dispatch. The router walks the supertype chain
-to handle custom viewpoints that specialize stdlib viewpoints.
+to handle custom viewpoints that specialize stdlib viewpoints. Dispatch first checks
+the view's declared `render` target for an exact match against `asTreeDiagram` or
+`asInterconnectionDiagram`, which takes precedence over the qualified-name/supertype
+heuristic entirely.
 
 **Diagnostic model mirrors ReviewMark.** `SysmlDiagnostic` mirrors ReviewMark's
 `LintIssue` in structure and philosophy: file/line/col location, severity enum,

docs/design/sysml2-tools-core/rendering.md

@@ -56,11 +56,14 @@ flowchart TD
 - *Contract*: `string ViewName`, `SysmlWorkspace Workspace`, `SysmlViewNode? ViewNode = null`.
   `ViewNode` is the view's resolved AST node, giving a layout strategy access to the view's
   declared `render`/`expose`/`filter` body statements. Of these, only `ExposedNames` (and its
-  resolved `Expose` edges) drives content scoping; `RenderTargetName` names a rendering
-  style/format per the SysML v2 grammar and is captured as inert metadata only (it never
-  affects scope or resolution); `FilterExpressionText` is captured as raw text and not yet
-  evaluated. `ViewNode` is `null` for the `--auto` synthesized view, which carries no AST node
-  of its own.
+  resolved `Expose` edges) drives content scoping — `RenderTargetName` never affects which
+  elements are included in the diagram. `RenderTargetName` does, however, drive **strategy
+  selection**: `DiagramTypeRouter` recognizes `asTreeDiagram` and `asInterconnectionDiagram` and
+  routes to the browser and interconnection strategies respectively ahead of the name/supertype
+  heuristic; any other value (including `null`, `asElementTable`, or `asTextualNotation`) remains
+  inert, with no corresponding strategy selection or diagnostic. `FilterExpressionText` is
+  captured as raw text and not yet evaluated. `ViewNode` is `null` for the `--auto` synthesized
+  view, which carries no AST node of its own.
 
 **Theme**: Visual configuration record.
 
@@ -111,12 +114,17 @@ flowchart TD
 - *Type*: Internal static class.
 - *Role*: Router.
 - *Contract*: `static ILayoutStrategy GetStrategy(object viewNode, SysmlWorkspace workspace, out string? unsupportedMessage)`.
-  Inspects the view node's name and declared supertype names (case-insensitively) for a recognized
-  view-kind marker, in priority order — Interconnection, StateTransition/State, ActionFlow/Action,
-  Grid/Matrix/Tabular, Browser/Tree, then Sequence — and returns the matching concrete
-  `ILayoutStrategy`, falling back to `GeneralViewLayoutStrategy` for unrecognized views or non-view
-  nodes. The `unsupportedMessage` out-parameter is reserved for future unsupported view kinds and is
-  currently always null because every view resolves to a strategy.
+  First checks the view's declared `render` target for an exact, case-sensitive match against
+  `asTreeDiagram` (routes to `BrowserViewLayoutStrategy`) or `asInterconnectionDiagram` (routes to
+  `InterconnectionViewLayoutStrategy`), taking precedence over the heuristic below; any other
+  render target value (including none, `asElementTable`, or `asTextualNotation`) falls through
+  unchanged. Absent a recognized render target, inspects the view node's name and declared
+  supertype names (case-insensitively) for a recognized view-kind marker, in priority order —
+  Interconnection, StateTransition/State, ActionFlow/Action, Grid/Matrix/Tabular, Browser/Tree,
+  then Sequence — and returns the matching concrete `ILayoutStrategy`, falling back to
+  `GeneralViewLayoutStrategy` for unrecognized views or non-view nodes. The `unsupportedMessage`
+  out-parameter is reserved for future unsupported view kinds and is currently always null
+  because every view resolves to a strategy.
 
 **StdlibFilter**: Standard-library element filter.
 

docs/design/sysml2-tools-core/rendering/internal.md

@@ -17,8 +17,12 @@ whether an element belongs to the standard library.
 
 #### Design
 
-`DiagramTypeRouter` inspects a view's name and declared supertype names for a recognized view
-kind (interconnection, state transition, action flow, grid/matrix, browser/tree, sequence) and
+`DiagramTypeRouter` first checks a view's declared `render` target for an exact match against
+`asTreeDiagram` (browser/tree strategy) or `asInterconnectionDiagram` (interconnection strategy),
+taking precedence over the name/supertype heuristic; other render targets (including
+`asElementTable`, `asTextualNotation`, or none) have no effect. Absent a recognized render
+target, it inspects a view's name and declared supertype names for a recognized view kind
+(interconnection, state transition, action flow, grid/matrix, browser/tree, sequence) and
 returns the matching strategy, defaulting to the general view strategy. To keep diagrams focused
 on the user's model, the view strategies omit standard-library elements by testing each qualified
 name with the `StdlibFilter` helper. The `DiagramTypeRouter` unit is described in its own chapter.

docs/design/sysml2-tools-core/rendering/internal/diagram-type-router.md

@@ -16,9 +16,22 @@ diagnostic message when no strategy can be determined.
 
 ###### `GetStrategy(viewNode, workspace, out unsupportedMessage)`
 
-Returns the strategy for the view. When the node is a view, the router tests the view's name
-and its declared supertype names (case-insensitively) for a recognized view-kind marker, in a
-fixed priority order: Interconnection, then StateTransition/State, then ActionFlow/Action, then
+Returns the strategy for the view. Dispatch first checks the view's declared `render` target
+(`SysmlViewNode.RenderTargetName`) for an exact, case-sensitive (`StringComparison.Ordinal`)
+match against a recognized rendering-kind name: `asTreeDiagram` selects the browser (tree)
+strategy and `asInterconnectionDiagram` selects the interconnection strategy, taking precedence
+over the name/supertype heuristic below regardless of the view's own name or declared
+supertypes. `asElementTable`, `asTextualNotation`, any other unrecognized rendering-kind name,
+and a `null` (absent) render target are deliberately left unmapped: they have no effect and fall
+through unchanged, with no diagnostic, to the name/supertype heuristic. `asElementTable` is left
+unmapped because its `TabularRendering` semantics (a per-row/per-column table composition) are
+fundamentally different from `GridViewLayoutStrategy`'s matrix layout, not merely a naming
+variant of it; `asTextualNotation` is left unmapped because it is a non-graphical rendering
+style with no corresponding `ILayoutStrategy` implementation.
+
+When no render target matches, the router falls back to testing the view's name and its
+declared supertype names (case-insensitively) for a recognized view-kind marker, in a fixed
+priority order: Interconnection, then StateTransition/State, then ActionFlow/Action, then
 Grid/Matrix/Tabular, then Browser/Tree, then Sequence. The first marker that matches selects the
 corresponding strategy. When no marker matches — or the node is not a view — the router returns
 the general view strategy. The fixed order resolves views that carry more than one marker

docs/gallery/README.md

@@ -5,9 +5,13 @@ generated from an interesting example system. Every model is rendered to both
 **PNG** (raster, in [`png/`](png/)) and **SVG** (vector, in [`svg/`](svg/)).
 
 All diagrams are produced by the `sysml2tools render` command directly from the
-SysML v2 textual models in [`models/`](models/) — no manual layout. The view kind
-is selected automatically from each view's name (see the
-[rendering roadmap](../../ROADMAP.md) for the dispatch rules).
+SysML v2 textual models in [`models/`](models/) — no manual layout. Where a
+model declares an explicit `render asTreeDiagram;` or `render
+asInterconnectionDiagram;` statement (the two rendering kinds SysML2Tools
+currently implements), that takes precedence; otherwise the view kind is
+inferred from each view's name (see the
+[DiagramTypeRouter design](../design/sysml2-tools-core/rendering/internal/diagram-type-router.md)
+for the full dispatch rules).
 
 To regenerate the gallery, run for each model:
 
@@ -51,7 +55,9 @@ SVG: [`svg/BatterySubsystemView.svg`](svg/BatterySubsystemView.svg)
 Shows the internal structure of a part: nested part usages placed by the
 interconnection layout engine (a façade over the layered pipeline), ports on box
 boundaries, and connectors routed between them.
-The motherboard sits at the hub of the component connections.
+The motherboard sits at the hub of the component connections. The view declares an
+explicit `render asInterconnectionDiagram;` statement, so the interconnection
+strategy is selected directly rather than inferred from the view's name.
 
 Model: [`models/02-computer-interconnection.sysml`](models/02-computer-interconnection.sysml) ·
 SVG: [`svg/WorkstationInterconnectionView.svg`](svg/WorkstationInterconnectionView.svg)
@@ -153,7 +159,9 @@ SVG: [`svg/CarLineageGridView.svg`](svg/CarLineageGridView.svg)
 ## 7. Browser View — Avionics System
 
 Shows the membership hierarchy of nested packages and definitions as an indented
-tree with parent-to-child connectors.
+tree with parent-to-child connectors. The view declares an explicit `render
+asTreeDiagram;` statement, so the browser strategy is selected directly rather
+than inferred from the view's name.
 
 Model: [`models/07-avionics-browser.sysml`](models/07-avionics-browser.sysml) ·
 SVG: [`svg/AvionicsBrowserView.svg`](svg/AvionicsBrowserView.svg)
@@ -168,7 +176,9 @@ Shows a two-level nested Interconnection View. The `Computer` part contains a `b
 typed by `Motherboard`, which has its own internal `cpu`, `chipset`, and `ram` parts and
 connections. The motherboard's interior is laid out recursively (bottom-up) and nested
 inside the `board` container box, while the outer power and storage connections route
-between the top-level parts.
+between the top-level parts. The view declares an explicit `render
+asInterconnectionDiagram;` statement, so the interconnection strategy is
+selected directly rather than inferred from the view's name.
 
 Model: [`models/08-nested-interconnection.sysml`](models/08-nested-interconnection.sysml) ·
 SVG: [`svg/ComputerSystemInterconnectionView.svg`](svg/ComputerSystemInterconnectionView.svg)

docs/gallery/models/02-computer-interconnection.sysml

@@ -28,12 +28,15 @@ package DesktopComputer {
         connection c8 connect cpu to memory;
     }
 
-    view def WorkstationInterconnectionView {}
+    view def WorkstationInterconnectionView {
+        render asInterconnectionDiagram;
+    }
 
     // View-scoped rendering: exposing just cpu and memory narrows the diagram to those
     // two parts and the connection between them (c8), dropping every connection with an
     // endpoint outside the exposed scope (board, graphics, storage, psu, network).
     view CoreLinkInterconnectionView {
+        render asInterconnectionDiagram;
         expose Workstation::cpu;
         expose Workstation::memory;
     }

docs/gallery/models/07-avionics-browser.sysml

@@ -33,5 +33,7 @@ package AvionicsSystem {
         part def NavigationDisplay;
     }
 
-    view def AvionicsBrowserView {}
+    view def AvionicsBrowserView {
+        render asTreeDiagram;
+    }
 }

docs/gallery/models/08-nested-interconnection.sysml

@@ -28,5 +28,7 @@ package ComputerSystem {
         connection c3 connect board to storage;
     }
 
-    view def ComputerSystemInterconnectionView {}
+    view def ComputerSystemInterconnectionView {
+        render asInterconnectionDiagram;
+    }
 }

docs/reqstream/sysml2-tools-core/rendering/internal/diagram-type-router.yaml

@@ -36,3 +36,35 @@ sections:
           broadly applicable layout and is the natural fallback for an unspecified view kind.
         tests:
           - GetStrategy_PlainView_ReturnsGeneralViewStrategy
+
+      - id: SysML2Tools-Core-Rendering-Internal-DiagramTypeRouter-RenderTargetOverride
+        title: >-
+          When a view declares a render target of asTreeDiagram or asInterconnectionDiagram,
+          DiagramTypeRouter shall select the corresponding browser or interconnection layout
+          strategy, taking precedence over the name/supertype heuristic.
+        justification: |
+          A view's declared render target is an explicit, author-specified rendering-style
+          selection per the SysML v2 grammar. Honoring it ahead of the name/supertype heuristic
+          lets an author pick a diagram type directly, without relying on naming conventions,
+          and resolves any conflict between the two in the author's favor.
+        tests:
+          - GetStrategy_RenderAsTreeDiagram_ReturnsBrowserStrategy
+          - GetStrategy_RenderAsInterconnectionDiagram_ReturnsInterconnectionStrategy
+          - GetStrategy_RenderTargetPrecedenceOverridesNameHeuristic
+
+      - id: SysML2Tools-Core-Rendering-Internal-DiagramTypeRouter-RenderTargetUnrecognizedFallthrough
+        title: >-
+          When a view declares a render target other than asTreeDiagram or
+          asInterconnectionDiagram — including asElementTable, asTextualNotation, an unrecognized
+          name, or none at all — DiagramTypeRouter shall fall through unchanged to the
+          name/supertype heuristic, with no diagnostic.
+        justification: |
+          Rendering-style names with no corresponding layout strategy (asElementTable is a
+          fundamentally tabular composition distinct from the Grid View; asTextualNotation is
+          non-graphical) are not errors — render selects presentation, not content — so dispatch
+          must continue to resolve via the existing heuristic without regressing or emitting a
+          spurious diagnostic.
+        tests:
+          - GetStrategy_RenderAsElementTable_FallsThroughUnchanged
+          - GetStrategy_RenderAsTextualNotation_FallsThroughUnchanged
+          - GetStrategy_UnrecognizedRenderTarget_FallsThroughUnchanged