[alto] A unified approach to value schemas and ALTO maps

[Wendy Roome <[e-mail]>]

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