Help required: clarification on path expressions for nested lists

[StrayAlien]

Hi all, (@tarilabs , @etirelli , @agilepro) not an issue as such but a request for clarification of my understanding. I am writing some tests for assertions on using qualified names to access paths in contexts. Superficially, it all seems straight forward ... but it ain't. :-)

I get the simple cases, no issue but this one has me confused. It am not sure what the intention is here , nor how 'far' it goes. From the 1.2 spec (10.3.1.5 Contexts, Lists, Qualified Names, and Context Lists):

Nested lists encountered in the interpretation of N1.N2 … Nn are preserved.

Here is the example from the spec:

[{a: [{b: 1}, {b: [2.1, 2.2]}]}, {a: [{b: 3}, {b: 4}, {b: 5}]}].a.b = 
[[{b: 1}, {b: [2.1, 2.2]}], [{b: 3}, {b: 4}, {b: 5}]].b =
[[1, [2.1, 2.1]],[ 3, 4, 5]]

As the second line is a path operation on a lists of lists, not a list of contexts, it seems to indicate that a list of lists is 'visited' to 'find' a 'b' - in order to 'preserve' the lists. It this is the case I am not sure what the rules are here.

Some examples of possible assertions:

[ [ [ [ [ {b:1} ] ] ] ] ].b = [ [ [ [ [1] ] ] ] ]

(do we follow the lists as deep as they go ?)

[ [ [ {b: 1}] ], [ [ [ [ {b: 2} ], [ [ [ {b: 3}] ] ] ] ] ]  ] = [ [ [1] ], [ [ [ [2], [ [ [3] ] ] ] ] ]  ]

(this 'tree' of lists has three b 'leaves' that are at different depths - thus the outcome reflects those depths. It this what is required?)

What would be the answer here?:

[ [ [ [ [ {a:1} ] ] ] ] ].b

null, or [null], or [ [ [ [ [ null ] ] ] ] ]

?

To me this does all seem very odd ... and a bit likely spec writers on some flight of fancy. If I need to visit a tree .. I can recurse. IMO Not sure why this awkward complexity is needed.

Anyways, regardless, am I on the right track here?

Help appreciated.

Greg.

[agilepro]

We discussed this on Jan 4 and at that time Edson said that this example int he spec was incorrect, and said he would file a ticket to get it fixed in the next version. The coercion of singleton lists into the item value causes these problems, which is why this aspect was removed from 1.2 version.

Does that clear up all the problem? If so, let's close this issue.

[StrayAlien]

Thanks @agilepro - I am still not sure what is supposed to be implemented by (the very weird):

Nested lists encountered in the interpretation of N1.N2 … Nn are preserved.

Or do we just hold off on any impls until it is clarified in the spec? Happy to do so ... or just forget it entirely. :-)

[agilepro]

Does anyone know if Edson filed a ticket on this?

[tarilabs]

As noted in the meeting 2019-01-25 I will raise a ticket to the RTF as I believe the example from the DMN spec has a bug; this should have the RTF to clarify on that example/amend as necessary.

[tarilabs]

Raised as: https://issues.omg.org/browse/INBOX-806

[opatrascoiu]

The RTF ticket is https://issues.omg.org/browse/DMN13-133

[opatrascoiu]

There is a proposal to fix it.

[agilepro]

This was approved. But what is the answer to the question?

[tarilabs]

https://issues.omg.org/issues/DMN13-133

[agilepro]

Looks like this is done. Closing. If there are more questions, please reopen.