E.17.1:17 - Edition and Migration Notes

E.17.1:17.1 - Rename vs semantic change

A lexical rename that leaves viewpoint meaning and membership unchanged may be treated as a naming-layer migration. A change in membership, concern, admissibility, or member semantics is not just a rename; it requires another catalogue edition carrying the revised or new family declaration.

E.17.1:17.2 - Migration from local Sigma lists

Legacy MultiViewDescribing uses often publish only one local list of viewpoints. Migration should proceed by:

1. identifying recurring families across several such local lists,
2. publishing those families as explicit bundles,
3. then rewriting the local families to import the new ordinary family designator and declare any subset selection explicitly.

This sequence preserves provenance and avoids pretending that the reusable family had always existed.

E.17.1:17.3 - Migration from publication-face/form-bound naming

If a legacy practice uses one label interchangeably for a viewpoint family, a viewpoint, a report section, and a publication face, migration separates those positions explicitly. The ordinary family designator remains at the declaration layer; exact U.ViewpointRef values resolve P while any reader-facing viewpoint token is only P’s designator; publication-face names remain publication-layer vocabulary.

E.17.1:17.4 - Boundary to annex growth

Annex references are useful, but a declaration should not become a thin shell hiding all of its meaning elsewhere. The core declaration claim block still needs enough explicit member and family structure to stand on its own. Annexes deepen reuse; they do not replace the declaration’s primary claims.