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: http://json-schema.org/. 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://en.wikipedia.org/wiki/XML_schema 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] on behalf of [email protected]" <[email protected] on behalf of [email protected]> wrote: >Message: 1 >Date: Tue, 19 Jul 2016 03:08:04 +0800 >From: Jensen Zhang <[email protected]> >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] https://www.ietf.org/mailman/listinfo/alto
