Correct VSONCO rule for redefinition of nodes with multiple occurrences

I had a look at the Archie code (class SpecializedOccurrencesValidation) and realised I had forgotten to use effective_occurrences() (needed because any C_OBJECT might not have occurrences on it, and the equivalent has to be computed from the flat archetype or RM). I also missed a logic check at the bottom. My resulting code is a bit more concise than the Archie code because:

• Archie uses the check if (!allRedefinedNodeOccurrencesSummed.isLowerUnbounded()) { which should not be needed for type MultiplicityInterval since no modifier method should be able to set the lower to either unbounded or negative;

• Archie does both setUpper() and setUpperUnbounded() when setUpper() should arguably always unset upperUnbounded - at least my implementation of MultiplicityInterval does that.

Secondly, I have defined the main function collective_occurrences() on C_ATTRIBUTE whereas Archie includes it all in the validation visitor; my validator only has a small piece of code to do the check and generate the error. I see this as a style choice more than anything; having it on C_ATTRIBUTE means that it can be included in the spec under that class, whereas if all the logic is in the validator, we’d need to include pseudo-code for the validator.

As far as I can tell the Archie code is logically correct (and was a bit more correct than mine so I think we are in the right place. I have pushed the changes.

The current (preliminary) fix in Archie is in . it contains test archetypes we think should be valid and invalid - added to Archie already because not having this really made some very necessary things impossible. I also see some discussion here after merging this PR about lower bounds not being fixed, so it’s possible the Archie solution is still too strict - we intentionally made it a bit strict so it would be easier to relax to a more definitive version, without having to change any archetypes. I will check this version here later. So, I will check and answer later.

BTW, an archetype failing the new VSONCO rule now generates a message like the following:

ERROR (VSONCOm) object node at path /data/events[id3]/data/items[id6.1|Quantity field 1|] in specialisation group whose collective occurrences 4..* does not conform to node at parent path /data[id9]/events[id3]/data[id10]/items[id6] occurrences 1..3

Team, I’ve finally coded and tested (with some archetypes) the new VSONCO logic. Doing that caused some further minor adjustments to the logic, including what to do with child nodes in a ‘specialisation set' that have no occurrences override on them (perfectly valid).

There are some new test archetypes here that pass / fail in the right way, but we probably should have more. I’d rather rely on and anyone else ( ?) who might have more ‘real world’ test archetypes to try.

I’ll publish the updated spec soon. One possible issue is that I have provided the validation code in Eiffel language (i.e. looks more like Pascal, Python, etc but not much like Java or C#). The code above (see Execution tab) includes a lambda, which is an ‘agent’ in Eiffel. Do people think this is too hard to understand for people used to Java / C# / etc? I don’t really want to change it to Java as such because a) the code in the rest of the spec if also Eiffel (but it’s simple code), and also, the Java version isn’t that obvious either - you have to know Java lambdas. Note that I have used function currying, which doesn’t work in Java (at least not up to 11 AFAIK). Anyway, others here might have suggestions for how to make the formal code easier to understand.

Good point - I’ll use ‘intersecting’ - that’s the correct term. Plus, agree on italicisation.