[Bug]: Issues with the "PredefinedLocationsPublication" class model

[LBlaive]

What happened?

Comment reported during the Formal Vote ballot in 2018 by FR (no FR102). Two compositions have been added in this diagram between on one hand "PredefinedItinerary" and "PredefinedLocation", on another hand between "PredefinedLocationGroup" and "PredefinedLocation". This pattern existed in version 2 and was removed following an evolution request (no 85 of the old issue tracklist of 2012-04-23) when the initial works on Version 3 started. This model has several drawbacks:

• it leads to the recreation of numerous "references" (as stated in issue 85 of the issue tracklist);
• there is a risk of introducing circular references or references to nothing. The note existing in version 2.x to warn about this risk was removed when started version 3.0 and it is not present again;
• for the case of "Itinerary" the relation does not introduce any order introduced between Locations as it is stated in the class diagram of the "LocationReference" package.

Version

3

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[iancornwell1]

The old 85 became 135 in the next issue tracker, and still can be found here as #135. However the information preserved does not seem a complete description of the issue and its resolution.

[iancornwell1]

• numerous references - well, the current model can avoid that, by having PredefinedItinerary with Itinerary. It is true that somebody could choose that to make a much more verbose publication where every Point was a PredefinedLocation, which would probably not be a good idea, but that would be their choice.
• circular references - true, you can have a PredefinedLocation whose Location is a LocationReference that refers to the PredefinedLocation at the start of this sentence. But if somebody encodes that, it is probably a bug, so is it really worth writing a note to preclude such buggy usage?
• references to nothing - I am not sure what you have in mind, can you cite the instance pattern you have in mind where there is no location specified?
• I agree that currently PredefinedItinerary using multiple PredefinedLocation is not consistent with Itinerary. For Itinerary we thought it necessary to define optional Destinations and have an explicit index for the locations. If we still think that is necessary, then arguably we should have a concept between PredefinedItinerary and PredefinedLocation where we can do the same.

[LBlaive]

This issue needs to be addressed carefully. The additions were introduced when the standard was prepared for Formal Vote in 2018 following a comment received at the Enquiry but one can wonder if all the consequences were then analysed.

Indeed, since the “LocationReference” class model also allows defining a “Location” instance by reference and not directly, the association between the “PredefinedItinerary” and “PredefinedLocation” is redundant (idem between “PredefinedLocationGroup” and “PredefinedLocation”).

Note: The risk of “reference to nothing” mentioned in this comment does not seem real.

[iancornwell1]

Unless I have forgotten a requirement, I agree with this last comment. Unless anybody can remind us why we retained those 2 associations, I agree it would be an improvement to remove them.

[LBlaive]

Suggested change:

• to remove the compositions between on one side "PredefinedItinerary" and "PredefinedLocation", and on the other side "PredefinedLocationGroup" and "PredefinedLocation"
• Remove both attached notes.

[iancornwell1]

I considered whether this was an attempt to have publications of predefined locations and publications of predefined itineraries and groups without duplicating the data. But I was reminded that we can do that just by the Location in a LocationGroup or Itinerary being a LocationByReference, so the extra relations above seem redundant.