Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Possible error in Expansion Algorithm handling of nesting values (13.15) #262
I believe that the Expansion Algorithm's handling of nesting values in step 13.15 appears at the wrong nesting level of the algorithm, and that it should really occur after step 13 as a new step 14 (renumbering all subsequent steps). I suspect this is the case because:
If this is true, the language in the (current) 126.96.36.199 about "recursively" applying step 13 probably needs to be changed, as it will no longer be recursive.
This issue was discussed in a meeting.
View the transcriptNest handling at wrong level of indent
Rob Sanderson: #262
Rob Sanderson: There were a couple of expansion issues that would cause it to blow up. The problem is that nested entries in the context, would recursively require processing of that node.
… We figured out that it was just an indentation issue in the algorithm, which fixes the problem.
Proposed resolution: Accept API #262 and move 13.15 to new step 14, renumber following steps (and can close when complete) (Rob Sanderson)
Gregg Kellogg: +1
Rob Sanderson: +1
Jeff Mixter: +1
Ruben Taelman: +1
Tim Cole: +1
Ivan Herman: +1
Adam Soroka: +1
Pierre-Antoine Champin: +1
Resolution #6: Accept API #262 and move 13.15 to new step 14, renumber following steps (and can close when complete)
I see that this was resolved this morning, but I wanted to let you know that I'm now not certain that turning 13.15 into 14 is going to resolve the issue entirely. I believe test tn005 highlights a case that complicates this, and which will fail with 13.15 moved to 14. I'm not yet certain how to handle the recursion of
@kasei Step 14.2.2 is to repeat step 13 until there are no more nested values, but part of what should be repeated is step 14. My implementation breaks step 13 and 14 into a method (
@gkellogg I agree that using "repeat steps 13 and 14" captures the intent here.
However, the text now has some very strange linguistic use of "recursively" to apply to 2 steps in a much larger algorithm, one of which is not a recursive call. I think your approach of implementing 13 and 14 as a single method is intuitive here (and likely the sensible path for many implementations), but the current language obscures this fact. I think it would be wise to improve the language or structure to either make explicit that 13 and 14 are structurally related (and recursive) or to remove the "recursive" language (perhaps in favor of "repeat" and the use of "set
It is a recursive call, in that when invoking step 14 again, it may, in turn, use 13 and 14 with new inputs.
Of course, we could have moved all the sub-points of 13 down a level, and moved 14 back to 13.2, and just said to invoke step 13 recursively, but that seems to add a lot of structure that's not otherwise very useful.
Perhaps a note in step 14 that describes how 13 and 14 are related, and the purpose of doing such a "recursive" call is.
Yes, such a note might help. A number of times while implementing, I've felt that some of the structural relationships that may be completely obvious to you as both an editor and an existing implementor are not as obvious to me (and I suspect by extension to others who do not have your background with JSON-LD). I understand the resistance to making big structural changes in the algorithms at this point, but this is one of the cases where I think it might be very helpful for would-be implementors to get a more intuitive understanding of the algorithms.
Ideally I think this line of reasoning might have split 13 and 14 out into their own algorithm to make it dead-simple to understand that these things are related, recursive, and probably ought to be implemented as a stand-alone function/method. But I'm sure at CR you're past the point of being able to make a change like that.