Deals API 1.0 JSON Schema Unofficial

Decision records ·

D-010 What does sellerstatus code 4 mean on the tag 1.0-202602, where it is both "deal is complete" and "deal is archived"?

Gap Cited on main and at the tag 1.0-202602.

What the schemas do

Code 4 holds both meanings on the tag, and no code means complete alone; on main, the errata give complete 3 and archived 4.

Options

  • both Chosen

    Code 4 holds both meanings on the tag, and no code means complete alone; on main, the errata give complete 3 and archived 4.

  • archived

    Code 4 is archived, its last row, and complete has no code.

Why

The tag's table lists 4 twice, so a receiver that reads 4 can't tell a completed deal from an archived one. The schema doesn't choose between them: on the tag, 4's name joins both labels, and the lint reports the code given twice. main's errata give complete the code 3. The comparison of the two locks shows the change, and every build names the lock it was built from.

What we ask the specification to state

Release the errata: the tag 1.0-202602 still gives 4 to both "complete" and "archived". Say which release is the one of record, and bump the version when a code changes.

The specification lines it rests on

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

main

  • Object: Deal, the sellerstatus row's description: the value list L88 at 3028ddc
    0 (deal is active) | 1 (deal is paused) | 2 (deal is pending) | 3 (deal is complete (ie. selling scomplete (ie. selling system shows deal has completed)) | 4 (deal is archived (cannot be active again))

Tag 1.0-202602

  • Object: Deal, the sellerstatus row's description: the value list L88 at 938a5d1
    0 (deal is active) | 1 (deal is paused) | 2 (deal is pending) | 4 (deal is complete (ie. selling scomplete (ie. selling system shows deal has completed)) | 4 (deal is archived (cannot be active again))

What it shapes

Tag 1.0-202602: SellerDealStatus

The record's YAML file