TristanAlbers
commented
2 years ago Feature description
The feature works as follows: Whereas interpretations are currently scoped within a project, the new feature would move interpretations to be 'globally' applicable. Any new project would have access to the existing interpretations of a source -- possibly under the condition that the source is part of the project.
Current status
The implementation of this feature requires the complete restructuring of the current project. In the current project a model is the owner of structure of the project. This model can either be a LawSource model or a Flint model. The LawSource model is used to store and edit a Normsource whereas the Flint model is used to make interpretations by importing pieces of the Normsource into its own model. Each model also owns their own features meaning that features regarding to interpretation are not accessible inside the LawSource model and vice versa. There are some features which require acces to functions of both the LawSource and Flint languages, these features are stored in Flint.plugin which acts as a bridge between these languages.
Implementation of the feature
In my opinion a concrete description of the implementation is not possible since the feature is not defined clearly enough and there are many possible design choices code-wise. It would be advisible to create a seperate backlog with all of the functionalities 'reFACToring' should contain. These could also be defined as task inside #148
Predictions (working thoughts)
Probably everything inside the project would need to be restructured in some way. Storing facts/acts/duties inside lines brings a couple challenges.
Scoping
Scoping is used by features such as the typesystem and references. Currently everything is scoped based on the model. If facts/acts/duties are mapped beneath lines this scope is not longer viable. Research will need to be done to find the best way to create a new scope.
Exporting/Importing
Currently there are different exports/imports for LawSources, Flint and the EditorLanguage. If the models are restructured research needs to be done to find out how to best export and import the working project or pieces of the project.
Project structure
This is probably the most vague point with a lot of different design choices to be made. The project will need to be restructured in a way that makes sense for the new functionalies. An important thing to keep in mind is the way root nodes update inside a model. After some testing we concluded that when changes are directly made onto a single root node every root node inside the model refreshes. This causes performance issues inside the current project when the amount of root nodes exceeds ca. 1200. Research needs to be done about dynamically reassinging root nodes to different models so refreshing and editing root nodes doesn't cause performance issues.
Open questions
There are some open questions stated in the issue at #148
Introduction
One of the planned features was a rework of the relation between sources and their interpretation.
Briefly, the feature works as follows: Whereas interpretations are currently scoped within a project, the new feature would move interpretations to be 'globally' applicable. Any new project would have access to the existing interpretations of a source -- possibly under the condition that the source is part of the project.
For future implementation, we want to store the technical ideas about how to implement this.
Task breakdown
Write a brief, dev-oriented document outlining the following: