D-007 AdCOM says its lists "may be extended at any time" and that implementers "must accept" such changes within a version. Does a list's schema accept a code the list doesn't name yet?

What the schemas do

Each vocabulary holds the codes of its list at the pinned commit, plus vendors' codes where the list reserves them. An unknown code fails strict validation, which says that the value isn't a code of that revision. A receiver that must accept codes added later reads with a tolerant reader that keeps a code it doesn't know, which the SDK phase provides.

Options

• pinned-codes Chosen

  Each vocabulary holds the codes of its list at the pinned commit, plus vendors' codes where the list reserves them. An unknown code fails strict validation, which says that the value isn't a code of that revision. A receiver that must accept codes added later reads with a tolerant reader that keeps a code it doesn't know, which the SDK phase provides.

• open-to-integers

  Each vocabulary holds its codes, labeled, and is open to any other integer, so a code added later always validates.

• any-integer

  Each vocabulary accepts any integer, with no codes in its schema.

Why

The principle binds receivers: a receiver must not break on a code added after it was built. It doesn't make every integer a valid code: a sender that writes a code no list holds is still wrong for that revision. A schema of the pinned codes says exactly which codes the list held at its commit, and each release names that commit, so a new code arrives as a new release, which the release differ classes as additive. Opening every list to any integer would keep the labels but make the schema accept every typo, and a schema of no codes would lose what the lists say. So the schemas state the codes, and accepting a later code is a reader's choice. The tolerant reader that keeps an unknown code isn't built yet: the SDK phase builds it, and until then a receiver that must accept later codes validates with the next release. This stays a gap, since the text says receivers must accept new codes but not what a schema of a revision accepts.

What we ask the specification to state

Say, for each list, whether it is closed within a release, and how a receiver or an intermediary that knows only an older release handles a code it doesn't know: pass it through, drop it, or fail. Today the principle binds receivers, but a list's table gives no way to tell which codes a given release of AdCOM holds.

The specification lines it rests on

Each line is quoted as the record pins it. Expand an item to read the quote.

main

• AdCOM Principles, a requirement L179 at 26c59ba

  New objects and attributes may be added and enumerated lists may be extended at any time and thus implementers must accept these types of changes without breakage within a version number.

• List: Device Types, the row of 1 L3393 at 26c59ba

  1 | Mobile/Tablet - General

• List: API Frameworks, the row of 500+ L2885 at 26c59ba

  500+ | Vendor-specific codes.

Tag AdCOM1.0-202607

• AdCOM Principles, a requirement L179 at d67a6a8

  New objects and attributes may be added and enumerated lists may be extended at any time and thus implementers must accept these types of changes without breakage within a version number.

• List: Device Types, the row of 1 L3393 at d67a6a8

  1 | Mobile/Tablet - General

• List: API Frameworks, the row of 500+ L2885 at d67a6a8

  500+ | Vendor-specific codes.