wot-specs: revise WoT Binding and add registry-first Connectivity 1.1

README.md

@@ -19,6 +19,9 @@ See [`CONTRIBUTING.md`](CONTRIBUTING.md) for the full workflow, validation, and
 
 - `companion-specs/` — draft OPC UA companion specifications, one folder per domain.
   - `Generators/` — draft Companion Specification for electrical power **Generator Sets (GenSets)**: the information model (`Opc.Ua.Generators.NodeSet2.xml`), the NodeId assignments (`Opc.Ua.Generators.NodeIds.csv`), the specification document, and `tools/build_model.py` — a generator that emits the NodeSet, CSV, and reference tables from a single source of truth.
+- `wot-specs/` — Web of Things specification drafts and their supporting tools/examples, kept separate from OPC UA Core and domain companion-specification work.
+  - `WoT-Binding/` — draft **OPC UA — Web of Things (WoT) Binding**: a standalone revision of OPC 10101 that describes an OPC UA interface as a W3C Thing Description / Thing Model — preserving the official `uav` vocabulary, the Read / Write / Observe / Call and security mappings, and the URI rules — and adds a collision-safe model/platform vocabulary, NamespaceUri-qualified model-name hints beside definitive NodeIds, plus bidirectional NodeSet2 conversion. The semantic/readable mapping is primary, the complete `uav:nodes` projection is added only for source facts not yet expressible by the vocabulary, unmapped WoT members survive as pointer-addressed NodeSet extension residue, and `uav:nodeSet` is reserved for explicit byte archival or a demonstrated final fallback. Contains the specification, the JSON-LD context, an extension/preservation JSON Schema, worked examples, and a standard-library `tools/validate_local.py`.
+  - `WoT-Connectivity/` — draft **OPC UA — WoT Connectivity** (additive revision **1.1**): a **registry-first** revision of OPC 10100-1 that layers a W3C Thing Model / Thing Description **document registry** over the abstract [`xregistry/`](core-specs/xregistry/) base model (`WoTRegistryType` subtypes `RegistryType`; `ThingDescriptionGroupType`/`ThingModelGroupType` subtype `GroupType`; `ThingDescriptionFileType`/`ThingModelFileType` subtype the abstract `WoTDocumentType` `ResourceType`), exposed as a well-known `WoTRegistry` Object under the **Server** object (`i=2253`). The stored documents/versions are canonical; the OPC UA AddressSpace is a **derived, shadow-switched, generational projection** (Thing Models → types, Thing Descriptions → instances, affordances → Variables/Methods/EventTypes, links → References, forms → binder plans) with a `Refresh` Method, validation/load/refresh events, and desired/active version lifecycle. The full **OPC 10100-1 v1.02** model is **incorporated into the same combined NodeSet and namespace** — preserving every published NodeId (`1..172`), type and method signature — and its superseded management surface is marked `Deprecated` (per OPC 11030); the revised WoT Binding `uav` vocabulary is a normative JSON-LD dependency (not a NodeSet `RequiredModel`). Contains the specification, the generated combined NodeSet (`Opc.Ua.WoTCon.NodeSet2.xml`) / CSV, the pinned 1.02 sources under `legacy/`, the canonical `tools/build_model.py`, a standard-library `tools/validate_local.py`, and worked examples.
 - `core-specs/` — draft **extensions to the base OPC UA specification** (proposed additions to the `http://opcfoundation.org/UA/` namespace), intended for submission to an OPC Foundation Working Group. Each encoding/catalog folder below contains only the **normative** spec documents, its `README.md`, and the **base reference schema**; all tooling, examples, generated (non-base) schemas, and the shared validation package live under `core-specs/extras/` (a parallel, mirrored tree).
   - `observability-export/` — draft *OPC UA — Observability Export*: a small, transport-neutral layer that lets a Server, or a companion specification, declare **how its data lands in an observability system** — as OpenTelemetry (OTEL) **metrics, logs and traces** — so a generic read-only **bridge** can forward it over the **classic client/server (RPC) interface** and, **optionally**, over **PubSub (Part 14)** without understanding the domain. Contains the base NodeSet, CSV, and specification document, plus one **standardized subfolder per companion spec** (`pumps/`, `robotics/`, `facets/`, `di/`), each holding the companion-spec **addendum(s)** and the instance-overlay `NodeSet2.xml`. The generator tooling and example descriptor sources live under `core-specs/extras/observability-export/` (below). A non-normative **overview deck** ([`core-specs/observability-export/README.md`](core-specs/observability-export/README.md)) summarizes the why, what and how.
   - `avro-encoding/` — **Apache Avro (binary)** DataEncoding: a Part 6 mapping of the full OPC UA type model and a Part 14 **PubSub** message mapping, including **Action invoke/response** and **Discovery** messages. Reversible (`decode(encode(x)) == x`), with a NodeSet-driven schema generator and a SchemaId handshake.

core-specs/xregistry/OPC-UA-xRegistry.md

@@ -116,6 +116,12 @@ A writer registers a document by creating a file in the target group folder and
 
 On `Close` the server **auto-bootstraps** (§6.5): it assigns the entity's `xid`, `epoch`, `CreatedAt`/`ModifiedAt`, and any domain-derived attributes, and links the new file under its group and registry so it is immediately visible in all three representations. A server that is read-only (a published catalogue or a mirror) need not expose `CreateResource`.
 
+### 5.3 SecureChannel requirements
+
+Every operation that creates, modifies or deletes registry content or metadata shall be accepted only over an OPC UA SecureChannel using `MessageSecurityMode` `SignAndEncrypt`. This requirement applies to `CreateGroup`, `GetOrCreateGroup`, `CreateResource`, `GetOrCreateResource`, FileType `Open` for writing, `Write`, the `Close` that commits written content, `Delete`, `AddAttribute`, `RemoveAttribute`, and domain-specific Methods that change version selection, enablement or other registry state. Roles and Permissions remain independently applicable and may impose stricter authorization.
+
+Registry reads should use a secured channel. An implementation may expose read-only Browse, Read and FileType `Open`/`Read`/`Close` operations over `MessageSecurityMode` `None` when its deployment policy permits this. A client using such an endpoint shall not infer authenticity, integrity or confidentiality for the returned registry metadata or document bytes.
+
 ## 6 Information model
 
 The abstract base namespace is `http://opcfoundation.org/UA/xRegistry/`. Draft numeric NodeIds use the provisional `63000+` block; final NodeIds are assigned by the OPC Foundation. The four base ObjectTypes and their members are the normative node reference in Annex A. This clause describes their intent. Every Variable in the model has an explicit TypeDefinition: fixed attributes are `PropertyType` Variables, and each dynamic label is a `PropertyType` Variable under an `AttributesType` container (§6.6). A server **shall** set each group's, resource's and version's BrowseName to its identifier (`GroupId` / `ResourceId` / `VersionId`, a URL-safe token) so a client selects and filters entities directly from Browse results without a Read per candidate; the [*xRegistry — OPC UA API*](xRegistry-OPC-UA-Api.md) relies on this for read-free collection filtering.