-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Manage multiple-reference edit nodes #2
Comments
First I thought about a loop in parse_edit_node, but the cursor is previously changed by the different references and hence is not reliable, and the references are not necessarily article-reference nodes (see article 11 in constitutionnal law). Then I think it would be better to add some property in the reference nodes to define the cursor [begin,end]. Then, parse_edit_node will loop over its direct children and read these cursors. Such a proposition would be a first approximation, but a rebase operation as said in #1 could be more powerful. Another solution would be to create a visitor to split multiple reference children in a single edit node into multiple edit node, each containing a single reference child. |
This issue could be solved together with #6 either with a loop over multiple references in an edit node (previously collected by reference nodes which are direct children of the edit node), either by previously splitting these references which are direct children of the edit node into multiple edit nodes. I find these two solutions almost equivalent, with the slight difference that #6 will always need a loop in the edit node given multiple occurences of one word could happen. I almost started to solve these two issues, but I remembered that sometimes DuraLex falsely produces multiple reference nodes in an edit node, for instance in this amendment:
the DuraLex tree is something like
Currently this amendment works even for bad reasons, and I suspect there are a lot like this. If this issue is implemented, I guess they will no more work because the edit operation will operate on a very bad reference (the two first references treated alone). Hence I suggest to improve DuraLex first (its issue #9) to have reasonnably good DuraLex trees before applying them with SedLex. |
There is a visitor that will split edit nodes when there are multiple references. |
Oh thanks I didn’t know it because it is not in the binary file of DuraLex, I added it in Durafront and it seems it completely solve the issue, for instance with the amendment S-2018-27-18. I close this issue. (For readers, it’s ForkEditVisitor.) Also about the sub-issue for treatment of "articles 4 to 8", I find a dedicated visitor in SedLex could read the in-force law (or in the law proposal if provided and depending of the context) to search what articles exactly there are in the range (e.g. 4, 5, 5-1, 5-2, 6, 8), create as much article-reference as needed, and split them later by ForkEditVisitor. |
It should be used by DuraLex by default. |
Done in 35cd676. |
There are some edit nodes with multiple reference nodes (*) the operations must be executed multiple times on each reference node.
PS: even if I think it should not be managed in this issue but in another dedicated issue to be created, this could be a preliminary resolution for implicit lists like "articles 4 to 8" (where it could exists some non-linear articles like 4, 5, 5-1, 5-2, 6, 8 if e.g. article 7 was repealed and articles 5-1 and 5-2 were added after the initial redaction).
(*) Example: DuraLex tree currently created for the constitutionnal law XV-911 in its article 11
The text was updated successfully, but these errors were encountered: