1. Introduction

This document is part of the elaboration phase and describes the configuration mechanisms used in the editor.

As stated in the Vision document the editor embeds three levels of configurability , which are the core level, plug-in level and macro level.

2. Configuration needs

Here is a list of needs in term of configurability:

• Sort an element content either at document loading or at run-time.
• Change an element representation according to its content, eg. red background if it lacks an element. This may be supported at the core level using stylesheets, it is being discussed
• Specify how to represent an attribute, and what kind of edition mechanism it should has. For example we could have a custom-defined list of terms, a date, a number etc. These information are already present in the Schema.

Current issues:

• Configure view for attributes display.
• Current core configuration can only be done using the XSS.

3. XSS Stylesheets

XSS stands for XML Style Sheet, and is an XML-based CSS-like stylesheet language. Its main purpose is to allow to describe structured, heritable and extensible style attributes to configure the display of elements, which is actually made by the view extensions.

4. Editor configuration proposal

As mentioned before, configuration of the editor can be made on different levels:

• Core level which is done using the a file which implements the Configuration schema. This configuration file includes three sub-formats:
• An XSS stylesheet to define CSS-like attributes for the elements to be displayed.
• A View list which defines the different view classes that will be used and which parameters are given to the constructor.
• A schema translation which serves as a basis for element meta-information, which is actually is its schema constraints, associated view and XSS style.
• User level configuration which is done through macros that hook at specific application events, such as element insertion, deletion or change.

Most of the graphical configuration can be done with XSS, but views may sometimes require additional configuration. For example it is not really convenient to make a view plug-in for each element that has a specific way of representing its content. It would be rather helpful to allow the XMLViewFactory to post-configure create views.

Some view may also require behaviour configuration, eg. specific event listeners. In this case it is also awkward to use pure-Java extensions as it would imply to write one class per listener which can get things pretty messy.

In this perspective scripts could be used in correlation to XSS to make post-configuration of views which is not available otherwise. These scripts could be implementation of an interface or subclasses of a class that allows to configure a given view using a given element. Basically the main method would be View configure(View view, Element element) and would return a configured version of the view. We could think of a class implementation that would provide reflexion based mechanisms to infer the configuration method to be used.

For example the conf_View method would be the configuration method for elements of namespace conf and of name View . Elements with unspecified namespace would be _View.