Skip to content
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

Closed
Seb35 opened this issue Jul 23, 2018 · 6 comments
Closed

Manage multiple-reference edit nodes #2

Seb35 opened this issue Jul 23, 2018 · 6 comments

Comments

@Seb35
Copy link
Member

Seb35 commented Jul 23, 2018

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

@Seb35
Copy link
Member Author

Seb35 commented Jul 23, 2018

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.

@Seb35
Copy link
Member Author

Seb35 commented Dec 30, 2018

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:

À la première phrase de l’alinéa 2, substituer la référence :
« L. 3142‑22 »,
par la référence :
« L. 3142‑16 ».

the DuraLex tree is something like

type: edit; editType: replace
|--- type: alinea-reference; order: 2
|     |--- type: sentence-reference; order: 1
|--- type: word-reference
|     |--- type: quote; words: L. 3142-22
|--- type: word-definition
      |--- type: quote; words: L. 3142-16

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.

@JMLX42
Copy link
Member

JMLX42 commented Dec 30, 2018

There are some edit nodes with multiple reference nodes (*) the operations must be executed multiple times on each reference node.

There is a visitor that will split edit nodes when there are multiple references.
So IMHO this is not required and "forking" edits for multiple references is the way to go.

@Seb35
Copy link
Member Author

Seb35 commented Jan 1, 2019

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.

@Seb35 Seb35 closed this as completed Jan 1, 2019
@JMLX42
Copy link
Member

JMLX42 commented Jan 1, 2019

It should be used by DuraLex by default.

@Seb35
Copy link
Member Author

Seb35 commented Jan 3, 2019

Done in 35cd676.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants