foodPreferences — empty arrays in the examples and the extra favoriteDishes field

Group Phase Specification
1

Two questions about the JSON about foodPreferences.

1. Empty foodPreferences in the example scenario

Section 2.2 (“Food preferences”) states:

In addition, customers within a group can name ingredients they prefer to eat, exclude from eating, as well as favorite dishes. Each preference must use 1–3 of those properties.

In the example scenario JSON, however, three of the four customer groups have an empty array:

json

{ "id": 3, "type": "REGULAR", ..., "foodPreferences": [] },
{ "id": 2, "type": "CASUAL", ..., "foodPreferences": [] },
{ "id": 5, "type": "CASUAL", ..., "foodPreferences": [] }

We read “each preference must use 1–3 of those properties” as every customer group must specify at least one preference object (excludedIngredients, prefferedIngredients, favoriteDishes), in which case the example would be invalid.

So the question is if "foodPreferences": [] is valid input that our validator must accept, or should it be rejected? And if it is valid, is it correct that those customers then fall under “If there are no preferences, customers select the dish with the highest recipe id”?

2. favoriteDishes in the EVENT example

The EVENT customer group in the second example JSON looks like this:

json

{
  "id": 6, "type": "EVENT", "size": 16, "tableType": "COMMON",
  "visitingTick": 4, "foodPreferences": [],
  "restaurantTypes": ["EUROPEAN","AFRICAN"],
  "foodPreferences": [{"size": 16, "excludedIngredients": ["chicken","potato"]}],
  "eventEvening": 35,
  "favoriteDishes": {"EUROPEAN": "potato soup"},
}

Here favoriteDishes appears directly on the customer group instead in the foodPreferences array and as an object mapping a restaurant type to a dish name, whereas inside a foodPreferences element favoriteDishes is an array of dish names.

  • Is it really a map restaurantType → dishName and is it used for choosing the restaurant, for choosing the dish or both?

  • Can a group have both favoriteDishes and favoriteDishes inside foodPreferences? If they disagree, which takes precedence?

2

An additional question from my side, why exactly do we have two seperate foodpreference Lists?

3

foodPreferences: []is valid,

it means the element inside foodPreferences array has to satisfy this constraint, not the foodPreferences itself. [] just means "nobody in this group has preferences. Your second reading is right: those customers fall under “If there are no preferences, customers select the dish with the highest recipe id”

The EVENT favoriteDishes is genuinely a different field from the one inside foodPreferences, same name, different level, different type.

It is a map because an EVENT group considers several restaurantTypes and reserves 3 evenings before it knows which restaurant it gets, so the favorite has to be pinned per type

Event customer groups need a favorite dish for every restaurant type they consider visiting.

It is used for choosing the dish, not the restaurant.

A group can have both, and for EVENT groups it always does.

1 Like
4

There aren’t two. Listing A.2 accidentally prints the key "foodPreferences" twice on the same object, just a typo in the appendix, not a second concept. It isn’t even parseable: org.json rejects duplicate keys (Duplicate key "foodPreferences"), so that listing would fail before any validation rule ran.
There is exactly one foodPreferences array per customer group. What genuinely appears twice is the name favoriteDishes: once on the group (EVENT only, map) and once inside a preference object (array), also see above.

2 Likes
6

It has been adjusted.

3 Likes