Jensen, Richard and all,
I'd like to propose some other issues beside Jensen's:
1) How to represent the current data schema
2) How to declare the data schema precisely in the capabilities
Most JSON libraries would have no problem "parsing" the result, since a
JSONValue can always be converted to an array, an object or a primitive
type (scalar value). The question is how the application/client and the
server have the same understanding of the data. For example, some
extensions have already taken into consideration the compatibility with
multi-cost, but if such extensions are to be combined together, what is
the correct processing order?
One solution, as Jensen proposes, is to usea data schema. The client
can pre-compile its schema tree used in a request so that the ALTO
library can correctly understand the structure of the cost value.
However, instead of using the cost-schema, Ithink maybe it is possible
to extend the cost types directly, and all the options can be embedded
in the query. For example,
{
"cost-metric": "multicost",
"cost-mode": "compound", // or "vector", makes no difference now
"multi-cost-types": [
{"cost-metric": "calendar", "cost-mode": "compound",
"calendar-type": [
{"cost-metric": "routingcost", "cost-mode": "numerical"}
], "calendar-attributes": {...}}
]
}
However, it can still be very painful for the server to declare the
capabilities precisely. Haven't got a good solution for that now.
Regards,
Kai
On 19/07/16 03:08, Jensen Zhang wrote:
> Personally speaking, I think there are two issues about cost-type
> definition:
>
> 1) How to make the compound type compatible with RFC7285;
> 2) How to extend single cost-type easily. (Maybe we want to support
> generic types)
>
> A simple design I think is to introduce a special cost-mode called
> "compound". When cost-mode value is "compound", "multi-cost-types"
> field will be required. If the cost-mode value is not equal to
> "compound", we need to suppose the cost-type is always a single type.
>
> I don't think about the benefit from supporting generic types very
> clearly. We can introduce another some basic cost-mode like identity,
> vector and map.
>
> The recommended usage can look like:
>
> if meta.cost-type.cost-mode == "compound"
> ElemType is array && "multi-cost-types" field is required
> else if meta.cost-type.cost-mode == "numerical"
> ElemType is number
> else if meta.cost-type.mode == "ordinal"
> ElemType is non-negative int
> else if meta.cost-type.mode == "identity"
> ElemType is string
> else if meta.cost-type.mode == "vector"
> ElemType is array
> else if meta.cost-type.mode == "map"
> ElemType is object
>
> I think it is general enough to express arbitrary JSONValue. But I am
> not sure making the cost-mode cover generic types is helpful.
> Actually, "vector" and "map" are not single types. They are compound
> types indeed. If we want to express the cost-type accurately, one
> solution I think is to introduce a new field called "cost-schema" in
> cost-type:
>
> object {
> CostMetric cost-metric;
> CostMode cost-mode;
> [CostSchema cost-schema;]
> [JSONString description;]
> } CostType;
>
> The cost-schema field for cost-type is just like DTD for xml. And we
> can design complex compound types by using cost-schema.
>
> But I don't plan to deprecate "multi-cost-types" field. Because I
> think multi-cost is not a compound type but a class of compound types.
> For example, cost-maps with multi-cost [bw, hopcount] and with
> [hopcount, delay] can have the same capability [bw, hopcount, delay].
>
> The above is my current thought.
>
> Best,
> Jensen
>
> On Mon, Jul 18, 2016 at 8:11 AM, Y. Richard Yang <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi all,
>
> Several of us are reviewing the documents in the WG. Here is one
> common issue: We see that quite a few documents depend on encoding
> the types of the elements in a cost map. This is a complexity that
> the based protocol RFC7285 identifies and hence decided to make
> the type the generic type JSONValue. But in the spirit of being
> strong typed, a specific cost map needs an indication of the type.
> For those who need some review, please see:
>
> - Cost Map
> response: https://tools.ietf.org/html/rfc7285#section-11.2.3.6
> Requirements:
>
> media-type: application/alto-costmap+json
>
> meta: MUST include cost-type and dependent-tag of the network map
>
> data: "An implementation of the protocol in this document
> SHOULD assume that the cost is a JSONNumber and fail to parse
> if it
> is not, unless the implementation is using an extension to this
> document that indicates when and how costs of other data types are
> signaled."
>
> - Filtered Cost Map
> response: https://tools.ietf.org/html/rfc7285#section-11.3.2
>
> Defined as the same as Cost Map.
>
> - Endpoint Cost
> Service: https://tools.ietf.org/html/rfc7285#section-11.5.1
>
> media-type: application/alto-endpointcost+json
> meta: "The "meta" field of an endpoint cost response MUST
> include the "cost-
> type" field, to indicate the cost type used."
>
> The current definition of cost-type has two components: cost-mode
> and cost-metric,
> and cost-mode has two values defined: numerical and ordinal, both
> indicate a single
> number. At the same time, multiple active drafts
> (https://datatracker.ietf.org/wg/alto/documents/)
> need compound types for the elements of a cost map:
>
> - [multi-cost]
> This draft is probably the one which we need to resolve the issue
> the most urgent. Assume that
> it uses the current alto-costmap+json media type, then it cannot
> satisfy the requirement of "meta"
> including cost-type.
>
> - [cost-calendar]
> Cost calendar requires a compound data type as well.
>
> - [fcs]
> fcs depends on multi-cost and hence can have an issue as well.
>
> - [path-vector]
> The current definition of path-vector needs a vector of network
> elements.
>
> - [te-metrics]
> It appears that this document is fine, but may need to watch on
> related consistency issues.
>
> The preceding is not a minor syntax/encoding issue. How to handle
> types is a basic problem.
> Conceptually, a cost map, as in the base protocol is param'ed type:
> Map< String, Map< String, ElemType > >
>
> (Note: Some may argue that String above should be typed identifier.)
>
> So far, we have defined ElemType to be JSONValue, and used the
> cost-type to indicate more specifics:
> if meta.cost-type.cost-mode == "numerical"
> ElemType is float
> else if meta.cost-type.mode == "ordinal"
> ElemType is non-negative int
>
> My personal feeling is that we may need to start to introduce new
> cost-mode values to allow generic types. For those who are PL
> experts, it is a good chance to chime in. It is an important issue
> that the WG may want to work together to achieve a consistent,
> extensible design.
>
> Cheers,
> Richard
>
> References:
> -
> [multi-cost] https://datatracker.ietf.org/doc/draft-ietf-alto-multi-cost/
> - [cost-calendar]
> https://datatracker.ietf.org/doc/draft-randriamasy-alto-cost-calendar/
> - [fcs] https://datatracker.ietf.org/doc/draft-gao-alto-fcs/
> -
> [path-vector]
> https://datatracker.ietf.org/doc/draft-yang-alto-path-vector/
> -
> [te-metrics] https://datatracker.ietf.org/doc/draft-wu-alto-te-metrics/
>
> _______________________________________________
> alto mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/alto
>
>
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
