Hi all, Thanks for starting this discussion. If we are to extend the specification of a cost-type, I think it is necessary to extend it incrementally and smoothly. For instance by optionally adding cost-type members such as CostSchema cost-schema (to be defined) as Jensen suggested. Most of previous members of cost-types we defined with a consistent meaning.
For instance: - “cost-metric” points to a metric such as routingcost, hopcount, status and I don’t see how “multicost” or “calendar” can be a metric. - “cost-mode” was defined to indicate how the the cost *values* should be manipulated arithmetically e.g. numerical, ordinal, string, Boolean. To address your concerns, it may be worth to first discuss extensions on metrics, modes, and attributes extending the cost types while minimizing the creation of new modes and mime types. I would prefer to keep these members defined as they are otherwise there will be too much disruption with RFC7285. Likewise, a cost map conveys values described at least by their cost type and it is difficult to define map as a mode. My 2 cents for the moment, will continue later. Best regards, Sabine De : Gao Kai [mailto:[email protected]] Envoyé : mardi 19 juillet 2016 04:05 À : Jensen Zhang; Y. Richard Yang Cc : IETF ALTO; Randriamasy, Sabine (Nokia - FR); Wendy Roome; Nico Schwan Objet : Re: [alto] Discussion on how to encode element values of a cost map 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 use a 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, I think 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
