Providing the RDFA-editor to third parties

This document includes an analysis on how the lblod rdfa-editor could be provided to third parties. It includes an overview on:

• Approaches on how to include the base editor inside an application

• Approaches on how to include editor plugins

• The way third parties can load existing documents inside an instance of the editor

Onderstaande tekst werd gebruikt om een overzicht en extra vragen in een excel overzicht te visualiseren. De ontbrekende elementen zouden daar moeten aangevuld en besproken worden.

https://vlaamseoverheid.sharepoint.com/sites/ABB_GN/Overleg/Forms/AllItems.aspx?newTargetListUrl=%2Fsites%2FABB%5FGN%2FOverleg&viewpath=%2Fsites%2FABB%5FGN%2FOverleg%2FForms%2FAllItems%2Easpx&id=%2Fsites%2FABB%5FGN%2FOverleg%2Fdrempels%203rd%20party%20use%20editor&viewid=636f2dc6%2Dbf0a%2D4f81%2Db746%2D0a7d874efcd6vlaamseoverheid.sharepoint.com

Including the base editor inside an application

When including the editor inside their application, third parties should have 4 approaches:

• Using the @lblod/ember-rdfa-editor ember addon directly: this is the most technical approach. When using this package, third parties can customize and configure the editor extensively.

• Using a pre-built version of the editor: this is a batteries-included approach. This approach does not require any configuration by default. Third parties have the option to configure this version of the editor with a minimal and simple API. Additionally, they have the option to override some editor styling.

• Including a hosted version of the editor using an iframe. This is the most limited approach. Third parties have limited control over the editor instance.

• (Optional) A more technical approach: splitting up the @lblod/ember-rdfa-editor ember addon.

Using the @lblod/ember-rdfa-editor package directly

This is the approach that gives third parties the most control over an editor instance. As this package is an Ember.js addon, it must be installed inside an Ember.js application. This is the most technical approach which gives third parties complete control over the underlying API of the editor. It allows them to write custom widgets and plugins and integrate them in the editor. While this approach gives third parties the most extensive API, it is also the most technical approach and is not plug and play.

Advantages

• Extensive API which gives developers the option to customize the editor to their needs. Developers can add custom widgets, nodes, Prosemirror plugins etc.

Drawbacks

• The @lblod/ember-rdfa-editor package can currently only be used inside an Ember.js application.

• This approach does not come with batteries included and seems less good of a solution for a plug and play scenario.

A batteries-included approach: a pre-built version of the editor

This approach allows third parties to integrate an already pre-built version of the editor inside any web application. While the editor API of this approach is not as extensive as the more technical approach described in the previous section, it does require less configuration to set-up. This approach should include a minimal and simpler API that at least provides the following features:

Feature	Complexity
Access to an editor controller which can be used to execute actions inside the editor	Easy
The possibility to enable/disable plugins and features of the editor on the fly.	Medium
Functionality which can be used to react to different underlying state changes of the editor (such as document and selection changes).	Medium

A hosted approach: including an instance of the editor in an iframe

Another potential approach is to host an instance of the editor online and provide third parties with the option to include the hosted version inside their application using an iframe. While this is the most plug-and-play approach, it also provides less configurability and control over the editor instance. Research should be performed to determine how configurable such a hosted version should and can be.

(Optional) A new, more technical approach: splitting up the @lblod/ember-rdfa-editor ember addon.

While the @lblod/ember-rdfa-editor ember addon provides developers with an editor package which can be controlled through an extensive API, it has one major drawback: it may only be used in Ember.js applications. This section proposes a new approach which includes seperation of the editor UI and editor logic. In this approach, the current @lblod/ember-rdfa-editor is split up into two (or more) new packages:

• A vanilla Javascript package which contains all the internal logic of the editor. This package contains the logic to set-up a basic editor and provides an API to control and configure the editor. It can be used across all types of Javascript Projects.

• An Ember.js addon which contains composable UI components which can be used in combination with the package containing the editor logic. This package needs to be installed inside an Ember.js application. This package is optional.

In order to add an instance of the editor to their application, a developer needs to install at least the package containing the internal logic of the editor. After installing this package they have two different options:

• If the developer is installing the editor in an Ember.js application, they have the option to install the Ember.js addon containing the composable UI components.

• In all other cases, the developer has the option to write their own UI components/interface and use the editor API provided by the package containing the internal logic of the editor.

Advantages

• Extensive API which gives developers the option to customize the editor to their needs. Developers can add custom widgets, nodes, Prosemirror plugins etc.

• The package containing the internal logic of the editor can be installed in any Vanilla Javascript application

• Developers still have the option to install the Ember.js specific UI component library.

Drawbacks

• This approach does not come with batteries included and seems less good of a solution for a plug and play scenario.

Note: this approach is merely a proposal and has not been implemented yet. It will require a considerable rework of the current editor package.

Editor plugins

Third parties should have the ability to choose which plugins they want to enable in an editor instance. Some of the plugins which are currently maintained are heavily dependent on the Gelinkt Notuleren application. In order to make these plugins more accessible to third parties, they should be implemented in a more generic way and be configurable. Several of these plugins rely heavily on remote SPARQL endpoints, third parties should be able to use these plugins in combination with their own SPARQL endpoints.

Overview of the currently maintained plugins

Plugin	Depends on remote endpoint	Depends on the Gelinkt Notuleren application
Article-structure plugin	No	No
Besluit plugin	No	No
Besluit-type plugin	Yes	Yes*
Citation plugin	Yes	No
Rdfa-date plugin	No	No
Roadsign-regulation plugin	Yes	No
Standard-template plugin	Yes	Yes
Table-of-contents plugin	No	No
Variable plugin	Yes	No

*can be made independend of GN with only minimal work

Usage of in-house data

Using the editor API provided by the different approaches, third parties should be able to load existing documents inside the editor. The API provides methods in order to load data in and extract data from an editor instance.