Error/Problem some additional discussion

[ue71603]

Christophe: Ce que je voulais ponter à Cologne, c'est le fait qu'OJP hérite des interfaces SIRI et qu'il y a déjà toute une série de mécanismes permettant de remonter de problèmes (en rouge ci-dessous):

Si on détaille l'ErrorContion dans la partie ServiceDeliveryStrucure, on a

J'y ai déplié le CapabilityNotSupportedError car il peut en particulier véhiculer des informations comme " element ‘OptimisationMethod’ with value ‘scenic’ not supported in a call to OJP_TripRequest." Pour moi, le "Problem" qui a été ajouté à toutes les réponses OJP ne me semble pas pertinent et est redondant avec ce qui est déjà disponible du fait de l'héritage de l'interface SIRI. Je serais donc plutôt favorable à spécialiser ce mécanisme de gestion d'erreur, plutôt que d'en créer un autre qui risque de générer des incompréhensions et de mauvais usages dans l'articulation entre les deux.

André: So, as I read your comments, you implicitely suggest reconsidering the new ProblemStructure. I see four possibilities:

1. Abandoning the new ProblemStructure and using the SIRI ApplicationErrors, which are already available / inherited, instead. This would require mapping the OJP Problem codes to SIRI error types – and switching back to the term «error» 😊
2. Extending ProblemStructure to be able to transmit additional details (like which parameters did cause the problem).
3. Sticking with ProblemStructure and not transmitting further details.
4. Keeping ProblemStructure – and using SIRI ApplicationErrors to transmit additional details. This wouldn’t require any change in the code, but in the documentation.

D is a compromise, but I would find it quite a viable solution.

Christophe: As explained in Cologne, I don't really understand what the new ProblemStructure brings that you can't say in the SIRI Error structure.... D Is Ok, provided that it adds on A .... if not A seems the best to me.

[ue71603]

We will have a look at this:

• Remove as much from Problems --> Error as possible.
• See if the rest should be a SIRI extension.

[ue71603]

Stephan: A short part in the documentation in SIRI should be referenced.

[ue71603]

Analysis: We would need to create new Error s with the substitionGroup="ErrorCode"

this would a bit look like this:

We have problems now on the XXXDelivery, but also on the XXXResult.

From the currently defined errors some could be transformed into Errors. OJPGENERIC_REQUESTNOTSUPPORTED: CapabilityNotSupported OJPGENERIC_FEATURENOTSUPPORTED: ParametersIgnored or CapabilityNotSupported OJPGENERIC_LANGUAGENOTSUPPORTED: n/a OJPGENERIC_EXCEPTIONFROMREQUESTEDLANGUAGE: n/a OJPGENERIC_DATAFRAMEREFNOTAVAILABLE: n/a OJPGENERIC_OTHER: OtherError FARE_OUTOFAREA: n/a FARE_JOURNEYNOTPERMITTED: n/a FARE_ADDITIONALCHARGES: n/a FARE_ADDITIONALTICKETS: n/a FARE_ROUTENOTFEASIBLE: n/a FARE_ALREADYCOVERED: n/a FARE_DATEOUTOFRANGE: n/a FARE_STOPPOINTUNKNOWN: n/a FARE_OTHER: OtherError LOCATION_NORESULTS: n/a LOCATION_UNSUPPORTEDTYPE: ParametersIgnored LOCATION_UNSUPPORTEDCOMBINATION: ParametersIgnored LOCATION_NOREFINEMENT: n/a LOCATION_USAGEIGNORED: n/a LOCATION_UNSUPPORTEDPTMODES: ParametersIgnored LOCATION_UNSUPPORTEDLOCALITY: ParametersIgnored LOCATION_OTHER: OtherError EXCHANGEPOINTS_NORESULTS: n/a EXCHANGEPOINTS _UNKNOWNDESTINATIONSYSTEM: n/a EXCHANGEPOINTS _UNKNOWNADJACENTSYSTEM: n/a EXCHANGEPOINTSOTHER OtherError TRIP_NOTRIPFOUND: n/a TRIP_ORIGINUNKNOWN: n/a TRIP_DESTINATIONUNKNOWN: n/a TRIP_VIAUNKNOWN: n/a TRIP_NOTVIAUNKNOWN: n/a TRIP_NOCHANGEATUNKNOWN: n/a TRIP_NOORIGIN: n/a TRIP_NODESTINATION: n/a TRIP_ORIGINDESTINATIONIDENTICAL: n/a TRIP_DATETIMEERROR: n/a TRIP_DEPARTUREAFTERARRIVAL: n/a TRIP_DATEOUTOFRANGE: BeyondDataHorizon TRIP_ORIGINEQUIVALENT: n/a TRIP_DESTINATIONEQUIVALENT: n/a TRIP_VIAEQUIVALENT: n/a TRIP_REALTIMEINCOMPLETE: n/a TRIP_ITTIMEEXTENDED: n/a TRIP_ITMODECHANGED: n/a TRIP_INCONVENIENTWAITING: n/a TRIP_OTHER: OtherError STOPEVENT_DATEOUTOFRANGE: BeyondDataHorizon STOPEVENT_LOCATIONUNKNOWN: n/a STOPEVENT_LOCATIONUNSERVED: n/a STOPEVENT_NOEVENTFOUND: n/a STOPEVENT_OTHER: OtherError STOPEVENT_LASTSERVICEOFTHISLINE: n/a STOPEVENT_NOREALTIME: CapabilityNotSupported TRIPINFO_JOURNEYREFUNKNOWN: n/a TRIPINFO_VEHICLEUNKNOWN: n/a TRIPINFO_NOJOURNEYFOUND: n/a TRIPINFO_NOGEOINFO: n/a TRIPINFO_OTHER: OtherError AVAILABILITY_NOSERIVCEFOUND: n/a AVAILABILITY_LOCATIONUNSERVED : n/a AVAILABILITY_LOCATIONUNKNOWN : n/a AVAILABILITY_OUTSIDERULES : n/a AVAILABILITY_SERVICEDISRUPTED: n/a AVAILABILITY_UNAVAILABLE : n/a AVAILABILITY_OTHER: OtherError LINEINFORMATION_LINEUNKNOWN: n/a LINEINFORMATION_OTHER: OtherError

After seeing this my suggestion would be to stick with the current solution, because:

• We can't give information back on the XXXResult only on the XXXDelivery
• About 90% of the problems are not covered by the Error.
• There is almost no synergy between the services. So we would have to define about 50 new error elements.
• Problems allows for more detailed elements

@Aurige , @herlitze , @normanoffel, @skinkie : From the conceptual and the implementation side: What do you think?

[ue71603]

Norman: If there is no good overlap, I would consider to have too things. Against mixing. I wouldn't enhance the complexity without a reason. Christophe: One OJPError and have everything in there.

PR create and have a look.

[ue71603]

will be continued here: https://github.com/VDVde/OJP/pull/336