Can a capability's values be URIs into an externally governed vocabulary, or must they be enumerated in source/?

[ptpge]

We are preparing reference data for a print vertical (background and data: #971). Print products are configurable goods: a product exists only once its options are chosen, from a controlled vocabulary of ~730 terms that is published with permanent URIs and changes under its own governance.

The question for maintainers: can a capability's schema declare a property whose values are URIs into such a vocabulary — validated by pattern and resolution, the way org.ptpge.print.identity does today — or does UCP expect every value a capability depends on to be enumerated inline in source/, as lodging does with room types and rate plans?

The answer decides how a print vertical can be shaped — and, more generally, how any configurable-goods vertical with a large, externally governed value space (print, signage, packaging, made-to-order furniture, industrial parts) can be. Thank you.

[IlyaKhalafi]

The current Schema Authoring Guide supports an open vocabulary. It recommends string values with documented well-known meanings and reserves enum for provably closed sets. That guidance does not require copying the roughly 730 terms into source/.

URI-valued strings can express those identifiers. Keep vocabulary membership and resolution as an explicit part of the capability’s contract. A pattern constrains the string, while format: "uri" describes URI syntax and can be annotation-only unless format checking is enabled. Neither establishes that the term exists or resolves to the intended definition. See the JSON Schema format guidance.

I’d document the vocabulary revision, how receivers handle unknown terms, treatment of deprecated terms and behavior when resolution is unavailable. The same guide asks open value sets to state unknown value handling in the description. That also lets implementers distinguish an unknown term from a temporary lookup failure.

For publishing, the contribution guide says vendor-specific capabilities can be self-hosted under a vendor namespace. Adoption into dev.ucp.* is a separate governance decision. The open-vocabulary guidance supports the representation; it isn’t approval of a particular print schema.

[ptpge]

Thank you — the Schema Authoring Guide's distinction (open string vocabularies with documented well-known values; enum only for provably closed sets) is the one we needed, and it answers the question for our purposes. The guide does not address externally governed vocabularies by name, so for the record, this is how org.ptpge.print.identity handles the four points you list — and we will state them explicitly in the capability's description:

• Vocabulary revision: the manifest's config carries the vocabulary base and its dataVersion; every release is dated and additive.
• Unknown terms: a UCP receiver tolerates the value, as the guide requires — an unknown URI does not break the line. What it cannot do is obtain an identity for it: the capability derives a content-addressed identity (a SHA-256 «fingerprint», see Print vertical for UCP: open vocabulary, schemas and product identity, ready to reference #971) from the bindings, and the reference validator refuses to issue one for a configuration whose binding is not in the vocabulary — so «unknown» surfaces as «no identity issued», not as a rejected transaction.
• Deprecated terms: a deprecated URI keeps resolving and names its successor; the validator accepts it and surfaces the successor.
• Resolution unavailable: membership is checked against a cached snapshot of the vocabulary at the declared dataVersion, so a lookup failure is distinguishable from an unknown term; resolution is never on the transaction's critical path.

Understood that this is support for the representation, not approval of a print schema. Self-hosting under org.ptpge.* is where it stays until there is adoption to show.

[ptpge]

Same need raised independently for footwear sizing (ISO/TC 137) in #971 — so the guidance above (URI-valued strings, membership and resolution as part of the capability’s contract, documented handling of unknown and deprecated terms) looks like the general pattern for configurable goods, not a print special case.