[#602] Add non-normative guidance for Templates

[wes-johnson]

[#602] Add non-normative guidance for Templates

Closes #602. Per the spec team decision on the issue: "a series of non-normative statements around
Templates… not going to fundamentally change how they're handled."

Guidance only — 0 assertions added, 0 removed, no mechanism change. 236 insertions, Chapter 6.

The Template section was 22 normative statements, 2 non-normative comments, and no examples — the
only construct in Chapter 6 without one, which is likely why complex datatypes read as hard.

The model, stated plainly

template_ref was explained only as "the name of the metric that represents the template
definition" — accurate and opaque. Now: a Definition declares a type once in the Edge Node's NMETA
and carries no values; an Instance is a value of that type naming it in template_ref. A Definition
answers "what does a motor look like", an Instance answers "here is a particular motor".

Parameters versus members

The distinction was never stated. Metrics are data; parameters are per-Instance configuration
(manufacturer, serial number, EU range) with defaults from the Definition. Rule of thumb: what you
would trend or alarm on is a metric, what you would label or scale that trend with is a parameter.

Nesting

Previously one clause. Now spells out that a Template member of a Definition is itself a Definition
(is_definition true, no template_ref), and of an Instance is an Instance (is_definition false,
template_ref names the member type).

Worked example (new subsection)

Three linked payloads telling one story:

• NMETA — a MotorType Definition: three metrics, one parameter (Manufacturer, default
  "Acme"), no values.
• DBIRTH — two Instances, Motors/Conveyor and Motors/Filler, both template_ref: "MotorType". The first overrides Manufacturer; the second omits it and inherits the default, so
  the parameter-default mechanism is visible rather than merely described.
• DDATA — the conveyor's RPM alone, demonstrating template-instance-members-data.

Uses "template": {…} as the JSON key, following the "command": {…} precedent in the NRESP example.

Choosing How to Express Structure (new subsection)

Frames the three mechanisms as choices about where structure lives rather than competing options:
Template → the type system (recurring shapes), metric-name folders → the name (one-off hierarchy),
device_tokens → the topic (subscribable subsets). Notes that a Template is the only one of the three
that is not interchangeable — the folder/topic split can be rearranged without changing a
fully-qualified name, but moving data into or out of a Template changes the payload structure and the
definition identifier.

Also covers the cost of change: any change to a Definition changes the NMETA's definition identifier,
so every consumer re-resolves. Adding a member to a widely instantiated type is more disruptive than
its size suggests.

Cross-Edge-Node Definition consistency

A Definition is scoped to the Edge Node that publishes it, so nothing stops two Edge Nodes publishing
different Definitions under the same type name. Where the same name and version appear on more
than one Edge Node, the Definitions should be structurally identical — same members, names, datatypes,
parameters. A name-and-version match with differing structure is a configuration error Sparkplug
cannot detect, because no Edge Node has visibility of what any other has defined. Where a type
genuinely differs, give it a different name or version.

This also clarifies what the version field is still for: definition_id is a hash of a single Edge
Node's metadata and cannot be compared across Edge Nodes, so distinguishing revisions of a same-named
type between Edge Nodes is the clearest use of version.

[ckienle]

Thanks Wes. Most of this is a real improvement: the parameters-vs-metrics distinction and the trend/alarm rule of thumb, the cross-Edge-Node consistency guidance and what version is still for, and the "Choosing How to Express Structure" section (the folder/device_tokens interchangeability matches the Topics chapter, and the cost-of-change note matches tck-id-payloads-defid-hash-changes).

Requesting changes for the nesting paragraph, which states the opposite of how Tahu encodes nested Templates, plus two problems in the worked example. Details are inline.

Nits, non-blocking:

• The DDATA example has no topic line, unlike the NMETA and DBIRTH examples above it.
• The example topics drop the Acme/Dublin/Packaging/ topic prefix that every other example in this chapter uses.
• Parameters are shown with a "dataType" key, but the Template.Parameter field is type in both the protobuf and the spec text.
• The first comment says a Definition "carries no values", but a few lines later a Definition's parameters may carry default values. "No metric values" (the wording used in the example prose) would be accurate.

[wes-johnson]

All four nits fixed in 66fc928:

• Added the missing topic line on the DDATA example.
• Restored the Acme/Dublin/Packaging/ prefix on all four topic lines, matching the rest of the chapter.
• Parameters now use "type", not "dataType" — that was my error; these were the only "parameters" blocks in the chapter, so nothing else was affected.
• "carries no values" → "carries no metric values" in both places, since a Definition's parameters may carry defaults.

[ckienle]

Thanks Wes. I checked 66fc928 against the version I reviewed. All four inline points and all four nits are fixed as described, and the new example sequence is correct (NMETA 0/0, DMETA 2/0, DBIRTH 3/1, DDATA 4/2 for seq/descriptor_seq, with the NBIRTH gap explained).

One optional wording point that doesn't block this: "A member cannot be a Definition" reads as a new constraint, and this PR is meant to add none. It does follow from the existing rule that a Definition omits template_ref, so it's accurate. "A member is never a Definition" would keep it descriptive.