Vex Vision

This document details my vision for Vex. It is meant both to guide development and to give users an understanding of upcoming features.

General

Vex is envisioned as an extensible platform for structured document editing and publishing. "Extensible" in this context means a couple of things.

Extensible by users. It should be easy for users to create new document types, or extend existing ones, and begin using them immediately. Users should be also be able to automate repetetive tasks, such as always inserting a title element for new documents.
Extensible by developers. The Eclipse platform upon which Vex is built provides a plug-in architecture by which third parties can contribute advanced functionality such as spell-checkers, integration with content managment systems, etc.

Vex should lower the bar for organizations considering using structured documents. The default installation should provide all the tools required to begin editing and publishing popular XML document types such as DocBook and xhtml, while allowing easy customization such as tweaking the style of generated output.

At the same time, Vex should be powerful enough for professional writers. It should be easy to perform most operations without removing one's hands from the keyboard. New document types should be easily added, and automated functionality should be possible using a built-in macro language.

Document Editing

The initial focus of Vex is to provide a comfortable environment for editing XML-based documents. While it is impossible to edit structured documents without being aware of their structure, Vex should work much like a wordprocessor, implementing many of the operations with which wordprocessor users are already comfortable. Some examples of this are as follows.

Pressing Enter at the end of a paragraph should cause a new paragraph to be created. Vex does this by splitting the current XML element into two elements.
Pressing Enter at the end of, say, a DocBook section title should insert a paragraph element after the title, instead of failing while trying to split the title element.
A toolbar button should be provided for toggling the current element between being a paragraph and a ordered or unordered list item.
Common shortcut keys should be implemented. For example, Ctrl-B should toggle whether the currently selected text is bold or strongly emphasized.
Table layouts and image rendering should be supported.

At the same time, Vex should allow the user to fully view and manipulate the structure of their documents.

The path widget displays the current caret location as a path through nested elements.
Selection highlighting shows which elements are selected, not just the text.
The Eclipse Properties view should allow the user to view and manipulate the attributes of the current element.
The Eclipse Outline view should show the full XML structure of the document. Clicking on an element in the Outline view should select that element in the editor. It should be possible to change the structure of the document by dragging and dropping elements in the outline view.
A new Contents view should display the logical contents of the document, e.g. all the title tags in a DocBook document. Element selection and re-organization should happen here just as in the Outline view.
A keyboard shortcut for growing the current selection to include the next enclosing element, and a corresponding one to shrink the selection, should be available.

Currently, Vex enforces partial document validity in that incomplete elements are permitted. For example, it is permissible to insert an empty DocBook section element even though each section requires a title element. Otherwise, Vex will only permit insertions of elements that will not violate document integrity. However, this approach has drawbacks: Vex cannot be used to fix existing invalid documents, and it becomes difficult to add structure to unstructured text. Vex should therefore permit invalid documents to be edited. Validation should happen in the background, and validity errors should be flagged in the left margin with a small icon, much as the Eclipse Java IDE flags compiler errors.

An advanced feature would be to allow custom editors for embedded documents to be added as plug-ins. For example, it should be able to create an SVG editor for editing embedded SVG documents. One half measure that may be easier to implement would be pluggable renderers. In the meantime, Vex should recognize the difference between the main document and an embedded document (e.g. by a switch in namespace) and render a simply informative box (e.g. a box containing the text "Embedded SVG document").

Configuration

One common complaint about many XML editors is that they are hard to extend with new document types. Vex treats all configuration items such as document types and styles as files in the workspace so that they can be easily created and modified by users. Future configuration items such as macros and transformation pipelines should also be stored as workspace files. The following features should also be implemented.

Configuration files should be represented with unique icons.
A new Configuration view should show only configuration items, grouped by type.
Vex should track all resources associated with each configuration item, and re-parse the item if any of the resources changes. Vex currenly provides some support for this. For example, changing a stylesheet immediately affects any document editors using the corresponding style. Vex should recursively follow resource references; for example, images referenced by stylesheets and entities referenced by DTDs should also be associated with the configuration item.
Parse errors in any configuration item should be flagged with a red 'X' in the Navigator and Configuration views, and listed in the Problems view.
Each configuration item has a unique ID. If Vex finds two or more items with the same ID, it should make the situation clear to the user, and allow the user to specify which is the preferred item.
It should be possible to package a number of configuration items and their related resources as a plug-in, and to publish that plug-in to an update site. This would support two categories of users: power users who are comfortable manipulating configuration items, and content creators who simply use the pre-defined configuration for a project via a plug-in.
If configuration items with the same ID are found both in a plug-in and in the workspace, the one in the workspace should take precedence.

Publishing

Vex is expected to become a platform for document publishing as well as document editing.

It should be possible to assemble individual XSLT stylesheets and output processors (e.g. the FOP processor for transforming XSLFO to PDF) into transformation pipelines.
It should be possible to transform an entire project at once, sending the results to local directory or a remote server via FTP, WebDAV, etc.