Wendy, Richard and all, Please see inline.
On 20/07/16 04:07, Y. Richard Yang wrote: > Wendy, > > Always enjoys reading your analysis! To make a long thread short, can > you add some more details to completely tighten potential loose > ends to the cost-spec idea, for example, > - is it part of cost-type? > - do we still use application/alto-costmap+json as media type after > this addition. > > I am willing to go forward with simple clean ideas... > > Thanks! > Richard > > On Tuesday, July 19, 2016, Wendy Roome > <[email protected] > <mailto:[email protected]>> wrote: > > Here is my somewhat cynical view on defining a schema for cost > types: It > will never work. > > Why not? First off, there already is a schema for JSON: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__json-2Dschema.org_&d=CwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=tMjkINTewC63-sscQdJeYK-wYn6pGhehKsY4Lxk6LRA&s=8tw4gzkH9lvG0lZuSr94Y5xbzTJkGJhabygtRIB5TjI&e= > . This started out as an IETF draft in the > now-concluded json group. It never became an RFC. Instead, folks > continued > that work independently. > > So if we want a json schema, why not use that? > > Second, schemas are inherently complicated and messy. Jensen mentioned > wanting something analogous to an XML DTD. However, DTDs are not > all that > frequently used, and they are one of many different competing > methods of > defining XML. See > > https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_XML-5Fschema&d=CwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=tMjkINTewC63-sscQdJeYK-wYn6pGhehKsY4Lxk6LRA&s=YFfK_zf03xF-gR2j1n6iDfRk7A_BE_1ivEcpws3gBUc&e= > > Third, the primary use for schemas is to enable automatic > validation: a > program can check that a chunk of data matches the schema. But > that does > not help a client figure out how to deal with that data. > > Fourth, schema can document the data format for humans. For example, > context-free grammars are wonderful for that, and with some > practice, they > are much easier to understand than a prose description. But it is not > clear a json schema would be as easy to comprehend. > > But finally, the biggy: > > Five: Clients need *semantics*, not syntax! A schema does not give > semantics. Does anyone expect an ALTO client to parse the schema and > impute the semantics? Remember clients do not need a schema to > parse json > -- json parsers do that without any help. A client really needs a > schema > to understand the semantics of the cost data. And I do not see any > way to > automate that. > I totally agree the "schema" here should be about semantics, since all JSONValue is either an array, an object (map) or a primitive type. For a cost map, if the client cannot understand the schema, either because of an unknown metric/mode or of an unsupported cost spec, the application surely cannot understand the semantics because there is no mechanism for a client to announce its capabilities. However, in the endpoint cost service/filtered cost map, the "schema" is included in the query, which is specified by the client. In this case, it is the server who must be able to understand the semantics. Since the server's capabilities (supported semantics) can be announced through the IRD entry, the client is able to determine what kind of "schema" is valid for a server. > > So here is my simple suggestion: add a new field, cost-spec. > cost-spec is > a string with a pointer to the human-readable specification of > this cost > type. For example, a uri or RFC####. The specification should > specify the > value of the cost-spec field for this cost type. Then a program > can check > that it recognizes the cost-spec value. For example, the default > cost-spec > value would be RFC7285. If a client does not recognize the > cost-spec, the > client should ignore that cost type. > Some "cost types" are customizable. Even clients/servers can recognize multi-cost, calendar, etc., clients may still need to specify the parameters. The clients/servers may still need some kind of compilation to figure out the correct structure of the cost value. Current extensions put all these information alongside the cost type and must take into consideration all previous submitted extensions, which results in unnecessary complexities in both the specification and the implementation. Instead, if we use a rooted semantic schema, it is very clear how the data should be understood by both the client and the server. > > Keep cost-mode as it is now: numerical or ordinal. This gives the > semantics for any numeric cost values (e.g., ordinal means "do not > scale > print"). > > > - Wendy Roome > > On 07/18/2016, 16:36, "[email protected] <javascript:;> on > behalf of > [email protected] <javascript:;>" <[email protected] > <javascript:;> on behalf of > [email protected] <javascript:;>> wrote: > > >Message: 1 > >Date: Tue, 19 Jul 2016 03:08:04 +0800 > >From: Jensen Zhang <[email protected] <javascript:;>> > >Subject: Re: [alto] Discussion on how to encode element values of a > > cost map > > > >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 > > > > > _______________________________________________ > alto mailing list > [email protected] <javascript:;> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=CwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=tMjkINTewC63-sscQdJeYK-wYn6pGhehKsY4Lxk6LRA&s=HYf-rjQswa0GmQMLb0lfSOj-dmN5t1sy0phtZHqQrbM&e= > > > > -- > Richard > > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
