Why ORDER exists
Questi contenuti non sono ancora disponibili nella tua lingua.
A new standard should have to justify itself. Here is the justification.
The gap
Section titled “The gap”Three bodies of prior art already touch restaurant data. None of them describes the operational restaurant.
| Prior art | Covers | Does not cover |
|---|---|---|
| schema.org | Menu, marketing profile, opening hours, reservations — for search engines | Any vocabulary for a table, a seat, a section, or a floor plan |
| Industry menu-sync specifications | Enterprise menu distribution to point-of-sale systems | Floor plans, tables, service periods |
| Reserve with Google | Materialised availability slots | A portable description of the restaurant itself; it is a proprietary feed for one consumer |
The floor, the tables, and the rules that make them bookable — the things a restaurant is actually built from — have no interchange format at all.
Rules versus slots
Section titled “Rules versus slots”There is a structural reason ORDER is not simply a subset of the availability feeds.
Those feeds carry materialised slots: every date, crossed with every time, crossed with every party size. That is an output. What a restaurant configures is a small set of rules — “lunch runs Monday to Wednesday, 12:00 to 15:00, in two turns of ninety minutes”.
Rules are the portable artifact. Slots are a derivation of them, and a lossy one: you cannot recover the rule from the slots. ORDER carries the rules and defines the derivation instead.
Why we align rather than depend
Section titled “Why we align rather than depend”ORDER tracks schema.org’s vocabulary field-for-field wherever a term exists, and projects onto it. We did not build on it, for two reasons.
schema.org is deliberately permissive — nearly everything is optional, ranges are unions, and cardinality is unconstrained. That is correct for a vocabulary meant to describe the whole web, and wrong for an interchange format, where a missing currency is a bug and not a stylistic choice. ORDER needs to be able to reject a document.
And schema.org has no table. That is the gap, so the part of ORDER that matters most is the part with nothing to inherit.
For the specs we could not build on, the reasons were practical: no published licence, no machine-readable schema, or a proprietary feed owned by a single consumer. We cite them; we do not depend on them.