Currently, WACline provides up to 111 features that can be reused to develop different variants for different annotation purposes. You can see a complete documentation of available features here. It includes a textual description and in some cases includes a screenshot of the user interface. However, some specific annotation workflows can require additional features. It is possible to contribute by forking the project and developing your own features to support new capabilities: new annotation storage connectors (like solid, mysql, elasticsearch,...), new annotation production purposes (describing, linking,...), new visualizations (diagrams, real-time charts,...). Try to always think about reusability by third parties, providing an understandable description, commented code or reusable modules, if it is possible. New contributions to the main project (bug fixes, enhancements, improvements, new features, optimizations) can be proposed opening a pull request.
Most of the common bugs and problems we have found (and how to solve them) while developing in WACline using Pure::Variants can be found here. Feel free to open a new issue whether it exists any problem in configuration, building or deploying steps.
In the following lines we present main aspects of WACline's development, that can help you to introduce yourself in how is it developed.
WACline follows W3C annotation recommendations in terms of protocol (how annotations are transported), model (how annotations are represented) and vocabulary (terms used to describe an annotation on the web). The following interactive concept map define some main concepts of wacline that will be used in feature modeling, component naming and among the source code of the project.
The feature model shows the functionalities that are implemented in WACline in a hierarchical structure. The following diagram only represents the most general groups and features developed in WACline.
Features are grouped in one of the main categories for annotations (Purposes, Operations, Annotation Servers, Target or Codebook). When developing new features, it is necessary to add it in the feature model, in the correspondin category, depending on what affects the new functionality (e.g.: a new functionality to check for spelling mistakes in comments, should create a feature in Purposes->Comments->SpellChecker). It can have restrictions or requirements (e.g.: Spellchecker requires Purpose comment to be activated). It can have attributes, which can be parameters that let you configure the spell checker (e.g.: default language).
WACline's main architecture components are illustrated in the following diagram. Basically it follows the same organization as root features in the feature model for the contentScript, while the entrypoint, as same as in all the browser extensions is the manifest, where declaration for background, popup and content script is done.
The initialization of components is done via ContentScriptManager.js for contentscript, while for background is done in background.js. Communication among browser extension components is done via chrome messaging, while communication among
WACline is an annotated SPL. Annotated SPLs resort to preprocessor directives (a.k.a. #ifdefs) to realize variability in code. The following figure provides a simple snippet as an example for feature Autocomplete. In configuration step, if Autocomplete is selected, the code between opening clause and closing close will be added to the corresponding script, block between lines #231-243. Otherwise, it is filtered out.
The coding style, with the specific diference of annotating code, it is done in Vanilla Javascript following Standard Javascript style.