Implement optional logistic data

[lecoqlibre]

We released logistic required data in the 1.9.0 and we should now discuss how to handle the optional data.

See issue #70.

Optional data

• bulk or not
• organic or not
• fragile or not (the notion of fragility is relative: in this area, we can consider that everything is fragile, according to Martin Bué, not only the eggs)
• stacking possible or not (we never had the information according to Martin)
• return of packaging (does the product is consigned)
• billing information, who is in charge: the producer, the buyer? Provide siret, name, address, tel, email
  • Proposal: same as contact of the place of distribution.

[RachL]

Nice!

One thing I'm not sure to understand: do we have already the notion of optional vs mandatory data in the standard?

[lecoqlibre]

Currently there is no real expression of constraints nor a mechanism to constraint data in the DFC standard. Technically, everything, every field is optional.

The required vs optional data here is related to logistics. They need the required (minimal) data to allow optimization.

We should define data Shapes one day and/or express them in the standard.

[RachL]

@lecoqlibre what are the consequences of mandatory info in the standard? The API is not published if the info are not there?

I understand minimal info is required to do optimization, but logistics data can be used for simple deliveries as well. I mean by that that it is maybe not the standard role to hold these constraints but rather the app which consumes these data?

[lecoqlibre]

No no, the standard shouldn't forbid the publication of an API even if it's incomplete.

You are totally right @RachL, it's up to the apps to hold the constraints. But the constraints should be expressed in the standard. For instance "if you want to use logistics optimization apps, you must provide the following required data", etc. The standard must tells the implementers what data they can expect and provide, right?

[RachL]

@lecoqlibre Right, ok. But then I think we need to define why something is mandatory and why something else is not. I guess it's mandatory when it matches a goal, right?

So if the DFC standard goal is to facilitate short food chain and limit their environmental impact, shouldn't data linked to optimization be mandatory in the standard? I assume here that the data listed are helping loading a truck completely in order to do less travels.

[lecoqlibre]

Right, ok. But then I think we need to define why something is mandatory and why something else is not. I guess it's mandatory when it matches a goal, right?

Yes and it is related to the validation of data provided by the user. We should ensure a consistent set of data. Implementers and users should know how to use data. An app could forbid to save some data is the form filled by the user does not contain all the "mandatory" values. Or if the data are saved even if incomplete, the user should be aware that some features won't be available (like logistics optimization).

So if the DFC standard goal is to facilitate short food chain and limit their environmental impact, shouldn't data linked to optimization be mandatory in the standard? I assume here that the data listed are helping loading a truck completely in order to do less travels.

Yes absolutely, if the producer wants to allow logistics optimization, he/she should provide the necessary data to do so.

In this issue, the "optional" is for data that logistics don't absolutely need to enable optimization: they can do it without this data even if it is better if it is provided. Mandatory data are listed in #70.