Hi Wendy, Sebastian, Ben and all, I see an interesting usage of a default value, so please let me know if I missed something. The protocol says Server MAY omit if the value is not defined, e.g. because it doesn't know the value maybe also because it does not want to expose it for this Cost Type on this src/dst pair. Likewise, both clients and servers would like to skip the burden of encoding/decoding src/dest pairs with no identified cost value. The Client can fill the information gaps on its own responsability. The proposed option that the ALTO Server provides guidance on the missing information with one default value assumes that: (i) the Server does not know the value but still wants to provide guidance and thus does provide a value which is DefaultValue. (ii) the Client can use DefaultValue on this cost metric with no risk to misunderstand the ALTO network information and with the guarantee of having a reliable guidance. Question: is point (i) allways true or are there other possible reasons? e.g. are there possibly "pathological" lacks of cost values that would need to be encoded with specific values, say BogusValue?
Actually DefaultValue may be useful in Cost Maps where it is very frequent and only a bunch say Maximum 10% of the s/d pairs have a different value, including BogusValue. In which case, it does not necessarily mean "ALTO Server does not know". In such a case, for the applicable Cost Map and Cost Type, the Client can catch DefaultValue and update only the s/d pairs with explicitely provided values. One may even figure that at some time or in some other circumstance, in a given Cost Map for a given Cost Type, the Cost value is unique = DefaultValue. The client then gets an empty map but the presence of a default value unambiguously indicates that information is provided. So when DefaultValue is "very frequent" (TBD) in a Cost Map, using it may optimize the transaction. If not the Server just doesn't provide one. Sabine -----Message d'origine----- De : [email protected] [mailto:[email protected]] De la part de Wendy Roome Envoyé : mardi 26 mars 2013 14:19 À : Sebastian Kiesel Cc : [email protected] Objet : Re: [alto] Cost map: undefined vs. default value Sebastian, Here's how I would encode that, assuming you have other costs for which you have known values: * "You should try these": use 0 (or something much lower than the other costs). * "Better avoid": use 1e99 (json allows scientific notation). * "I don't know": omit (I assume there are a lot of these). You might also consider defining additional cost types, such as: * avoid-these: 0 means "known to be okay", 1 means "known to be horrible", missing means "unknown". * best-picks: 0 means "excellent choice!", omitted means either "not as good", "known to be bad", or just "unknown". Presumably this would be a very sparse matrix. - Wendy On 03/25/2013 17:27, "Sebastian Kiesel" <[email protected]> wrote: >Wendy, > >how would you encode a cost map where most of the entries are "I don't >know", some are "you should try these" and some are "better avoid this >PID"? Reducing the number of PIDs so that I have only one (or very >few) "I don't know"-PIDs is not an option because I am planning other >cost maps with many details, too. > >Thanks >Sebastian > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
