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