Skip to content

IEEE register generated

19. Rendering (normative)#

19.1 The rendering constitution#

How a conformant client turns a hub's catalog into an actual user interface — categories, ranks, archetypes, widget patterns, regions, page composition, and the renderer conformance laws — is specified in full in RENDERING.md, the normative companion to this document (RFC-048). RENDERING.md is normative in the sense §8.8/§8.9 already are: a client claiming conformance to it MUST follow its MUST clauses exactly as it must follow this document's, and its enumerable vocabularies are frozen at the v1.0 tag under the same no-reuse/no-renumber discipline §5.7 applies to the wire registry.

This section states only what belongs in SPEC proper — channel-level semantics — and stops there by design: Valence describes what things are, never how they look (§1-7) is unchanged. No widget hint, layout rule, color, or pixel is ever wire-visible; RENDERING.md's entire vocabulary is either registry-numbered metadata (categories, ranks, units, ...) or purely client-side derivation and behavior. Whether a reference catalog and a reference client carry RENDERING.md's vocabulary is recorded in §18 item 23 and nowhere else (RFC-082).

19.2 The three-tier channel taxonomy#

Every channel a hub declares is exactly one of:

  • CORE (0x0001–0x007F) — machine-unspecific protocol machinery. A channel that assumes a motor, an actuator, or any physical capability MUST NOT be CORE.
  • STANDARD — machine-agnostic capability channels, declared per capability the hub actually has rather than per machine kind. A hub SHOULD expose the well-known channel for any capability it has (an axis's motion, a metered power, usage odometer, and the two standardized generator capability interfaces — a built-in pattern generator's role set, and the fray-d-shaped advanced-generator surface) carrying at minimum the field set RENDERING.md §2.2 names for that capability. This is SHOULD-level for existing hubs, MUST-level for hardware-hub-profile conformance from the v1.0 tag forward.
  • DEVICE — everything else, wholly catalog-described, exactly as today.

The taxonomy is a classification of intent, not a new wire mechanism: no frame changes, no core-channel changes. It answers "does a client that has never met this hub still render a good instrument for a capability it has," which pure catalog description (§8) cannot guarantee on its own — two axis-bearing hubs may otherwise expose their position, target and speed under names, groupings and units a generic client cannot correlate.

Capability discovery is unaffected. A STANDARD channel is discovered exactly like any other: its presence in the catalog is the capability advertisement (§6.3's "capability discovery is catalog introspection" is unchanged). STANDARD is a naming and minimum-field-set convention layered on top, never a new discovery mechanism.

Full capability-interface field tables, the derivation chain, and every rendering rule built on top of this taxonomy are RENDERING.md §2-14.