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

[Jensen Zhang <[e-mail]>]

Hi Wendy,

I want to support this idea. Please see comments inline.

On Wed, Jul 27, 2016 at 1:38 AM, Wendy Roome <
[e-mail]> wrote:

> 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.
>

Agree. And maybe another benefit from cidr => pid is for incremental
update. Once a cidr changes its pid, pid => cidr-array will require an
update of the whole cidr-array. But cidr => pid only requires an update of
one pid item.


>
> 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.
>

The specification metadata is very interesting and I like this design. But
I don't think RFC is the good solution for the specification citation. RFC
is human-readable, but it is hard for programs to parse RFC documents.
Maybe we find a schema language (or JSON schema) to specify the value
format.


>
> Here is a multi-cost map:
>    meta:
>       tuple-domains: [pid, pid, cost-type-name]
>       value-types:
>          3:
>

Is this a typo? Or what's the mean of '3:' here?


>             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.
>

It is also more flexible for incremental updates.


>
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto
>

I find this approach is also compatible with FCS, since FCS returns a fid
=> value map currently. I'd like to push it forward.

One more question: I think (src, dst) => cost map and (dst, src) => cost
map will have the same "tuple-domains" value, but they are different for
clients. How to differentiate them?

Best,
Jensen