Recently we talked about using "value schemas" so that we can add new
value types without defining new media types and message formats.
Here is another take on that approach. It unifies *everything* into one
common message format. Extensions simply require defining new entity
domains and (simple) value types.
So here's my idea. Every ALTO resource boils down to a mapping from 1-,
2-, 3- or 4-tuples to values. The tuple elements are names of entities in
a domain.
Examples:
Cost Map: (pid, pid) => value
Endpoint Costs: (addr, addr) => value
Endpoint Props: (addr, prop-name) => value
MultiCost Map: (pid, pid, cost-type) => value
MultiCost Calendar Map: (pid, pid, date-range, cost-type) => value
Network Map: (cidr) => pid
Note that I flipped the network map around. I think cidr => pid is cleaner
than pid => cidr-array, and it enforces the rule that a cidr is in only
one pid.
With this approach, the meta section of a response would give the domain
for each tuple element, and the value type. For example, here is a
conventional cost map:
meta:
tuple-domains: [pid, pid]
value-type:
specification: rfc7285
format: cost-type
parameters:
metric: routingcost, mode: numerical
map:
pid1:
pid1: ###, pid2: ###, ...
The value field gives document that specifies this value format (or a
registered name), a format name that is defined in that document, and any
additional parameters necessary to understand this value.
Here is a multi-cost map:
meta:
tuple-domains: [pid, pid, cost-type-name]
value-types:
3:
cost:
specification: rfc7285
format: cost-type
parameters:
metric: routingcost, mode: numerical
delay:
specification: rfc####
format: duration
parameters:
metric: propagation-time
map:
pid1:
pid2:
cost: 123, delay: 2ms
Here the different cost types have different value types. meta.value-types
means that the value depends on the 3d element of the tuple - the
cost-type-name - and gives the value format for each cost-type-name.
So are people interested in pursuing this approach? The good news is that
will unify everything. The bad news is it will replace everything in rfc
7285.
- Wendy Roome
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
