Subject: Re: [alto] Discussion on how to encode element values of a cost map

From: Wendy Roome <[email-masked]>
Date: Tue, 19 Jul 2016 12:57:12 -0400

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-masked] on behalf of
[email-masked]" <[email-masked] on behalf of
[email-masked]> wrote:

>Message: 1
>Date: Tue, 19 Jul 2016 03:08:04 +0800
>From: Jensen Zhang <[email-masked]>
>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
>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 19 Jul 2016 16:07:20 -0400

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-masked]>
wrote:

> 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
> 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=
>
> On 07/18/2016, 16:36, "[email-masked] <javascript:;> on behalf of
> [email-masked] <javascript:;>" <[email-masked]
> <javascript:;> on behalf of
> [email-masked] <javascript:;>> wrote:
>
> >Message: 1
> >From: Jensen Zhang <[email-masked] <javascript:;>>
> _______________________________________________
> alto mailing list
> [email-masked] <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

---

From: Gao Kai <[email-masked]>
Date: Wed, 20 Jul 2016 10:01:09 +0800

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,
> - do we still use application/alto-costmap+json as media type after
> this addition.
>
> On Tuesday, July 19, 2016, Wendy Roome
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
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.

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

> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto