adding processing model (closing #19)

[dret]

making it clear that members using the wrong type must be ignored.

[mnot]

A couple of things:

• I don't know what "Any member defined by this specification must be tested to use the type given in its definition" means.
• Generally, MUST is used to specify interoperability requirements; they should be testable. These MUSTs read oddly in that light.
• This isn't so much a processing model as it does specify error handling. Processing models generally specify behaviours; this doesn't (and arguably, this spec can't; that's up to the application in question)
• In the case that a problem type defines that a particular extension member MUST be present and valid, what happens?

So, I'd just say something like: "When interpreting problem details, errors (such as an an extension member whose value type is unexpected) might be encountered. In most situations, the information in other valid parts of the problem details can still be relied upon."

[dret]

On 2021-06-11 04:43, Mark Nottingham wrote:

• Generally, MUST is used to specify interoperability requirements; they should be testable. These MUSTs read oddly in that light.

wouldn't the test simply be whether the member values conform to the type given in the definition or not? if they don't, interop suffers because consumers don't know how to interpret the invalid type.

• This isn't so much a processing model as it does specify error handling. Processing models generally specify behaviours; this doesn't (and arguably, this spec can't; that's up to the application in question)

ok. to me, the first line of defense in behavior is to do this kind of validation. validate, then proceed. the original issue was asking what to do when validation fails.

• In the case that a problem type defines that a particular extension member MUST be present and valid, what happens?

i forgot that this is even possible. wouldn't that up for the type to define? that's hard for the generic spec to do. but i agree that saying this in the new section probably would help.

So, I'd just say something like: "When interpreting problem details, errors (such as an an extension member whose value type is unexpected) might be encountered. In most situations, the information in other valid parts of the problem details can still be relied upon."

thanks, i tweaked that a little and updated the PR.

[mnot]

OBE