Update to Shapeshifter specification version 3.1.0

[tomwetjens]

No description provided.

[albertGopacs]

Als ik kijk naar hoe nu de validatie is geïmplementeerd voor MessageId's en de eigenschap 'unsolicited' dan heb ik paar vragen danwel opmerkingen:

• mijns inziens betekent backwards compatibility dat als de eigenschap 'unsolicited' ontbreekt of null is, dat het oude gedrag vertoond wordt. Uitgaande van de specificaties (zoals ik die begrijp) betekent dit voor FlexOrder dat als unsolicited ontbreekt, FlexOfferMessageID verplicht is. Dit is niet zo in UnsolicitedFlexOrderValidator geïmplementeerd. (Voor FlexOffer zou het betekenen dat er niet gevalideerd wordt, wat nu ook zo in UnsolicitedFlexOfferValidator geïmplementeerd is.)
• ik zie dat er al twee validators bestaan die controleren op messageId. Namelijk ReferencedFlexRequestMessageIdValidator (valideert FlexOffer) en ReferencedFlexOfferMessageIdValidator (valideert FlexOrder). Beide staan toe dat de messageID ontbreekt en controleren alleen of een eventueel messageID bestaat.
  • En ik vraag me af of het niet wenselijk is om de validatielogica die nu in de nieuwe UnsolicitedXXXValidators zit, te verhuizen naar deze twee bestaande validators.

[tomwetjens]

• mijns inziens betekent backwards compatibility dat als de eigenschap 'unsolicited' ontbreekt of null is, dat het oude gedrag vertoond wordt. Uitgaande van de specificaties (zoals ik die begrijp) betekent dit voor FlexOrder dat als unsolicited ontbreekt, FlexOfferMessageID verplicht is. Dit is niet zo in UnsolicitedFlexOrderValidator geïmplementeerd. (Voor FlexOffer zou het betekenen dat er niet gevalideerd wordt, wat nu ook zo in UnsolicitedFlexOfferValidator geïmplementeerd is.)

You are correct. I will update the UnsolicitedFlexOrderValidator to have the correct backwards compatibility logic.

• En ik vraag me af of het niet wenselijk is om de validatielogica die nu in de nieuwe UnsolicitedXXXValidators zit, te verhuizen naar deze twee bestaande validators.

The main reason everything is in separate validator classes currently, is that we can have different rejection reasons (see UftpValidator#getReason).

1. Either we would have a very generic rejection reason (which might be okay),
2. or we'd have to refactor UftpValidator:
   • Refactor isValid method so that it returns a ValidationResult (containing a reason) instead of a boolean, so it can return different reasons
   • Remove getReason() method
   • This would mean a breaking change in the library.

What would you feel is the best course of action?

[albertGopacs]

• En ik vraag me af of het niet wenselijk is om de validatielogica die nu in de nieuwe UnsolicitedXXXValidators zit, te verhuizen naar deze twee bestaande validators.

The main reason everything is in separate validator classes currently, is that we can have different rejection reasons (see UftpValidator#getReason).

1. Either we would have a very generic rejection reason (which might be okay),

2. or we'd have to refactor UftpValidator:

   • Refactor isValid method so that it returns a ValidationResult (containing a reason) instead of a boolean, so it can return different reasons
   • Remove getReason() method
   • This would mean a breaking change in the library.

What would you feel is the best course of action?

Well, breaking changes for version 3 are out of question, I guess. And I think specific rejection reasons are a good reason to have separate validators. But an approach like jakarta validation with a ValidationResult is worth considering for version 4, I would say.

[nielsgijsen]

I approve

[albertGopacs]

voor een FlexOfferResponse is het FlexOfferMessageID niet optional.

[albertGopacs]

"if applicable" kan weer weg. En er staat "... this request is based on...", maar dat moet zijn "... this response is based on...". Ook bij FlexRequestResponseType staat dit verkeerd.

[albertGopacs]

Ik vraag me nu af of deze tekst niet in lijn gebracht zou moeten worden met wat er bij FlexRequestResponseType en FlexOfferResponseType staat...