WTP/VisualXMLEditor/Proposal

The Visual Editor for XML (VEX) is a proposed project under the Web Tools Project.

According to the Eclipse Development Process, this proposal is intended to declare the intent and scope of the Visual Editor for XML project as well as to gather input from the Eclipse community. You are invited to comment on and/or join the project.

Background

XML is being used more and more in document file formats. Such formats as Docbook, and DITA have been used to help provide a common format for document meta data. It helps separate the content from the presentation. As word processor formats move to XML like OpenOfficeXML and OpenDocument, it becomes more critical to have a WYSIWYG interface for these file formats. Most users that have to write books, articles, and other print related material don't want to deal with the tag markups for the files, but they want the convience and separation of presentation that these formats provide.

Introduction

The Visual XML Editor is a set of plugins that provide WYSIWYG editing ability for XML files. This can be used regardless of the XML involved, and uses CSS stylesheets to provide the formatting for the presentation layer. All that is needed is an stylesheet and an appropriate XML file to edit. It hides the XML tags from the user, allow them to have a word processor like experience but store the information in the native XML format.

Project Description

The eclipse VEX will be based off of a contribution from the VEX (Visual Editor for XML) project, originally created by John Krasnay and hosted at sourceforge.net. The goal of the project is to provide a WYSIWYG XML Editor primarily targeted for those using XML authoring file formats. It will be leverage existing XML support and frameworks from the Web Developers Tools project. Particularly, the Structure Source Editor, as well as the WTP validation frameworks. It will also make use of the DTD and possibly the XML schema support for the files as well. Future aditions could include RelaxNG as an additional language for the grammar and content model.

It's main focus though is to provide a word processor like feel for working with XML files.

Features and Goals

Note: This information comes from the VEX Vision statement, available at http://vex.sourceforge.net/vision.html.

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

Extendable

• 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, new templates provided, and easy ability to create stylesheets.

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

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.

Scope

The scope is limited to Visual Editing of XML files. Only items related to user functionality for the editor, as well as providing stylesheet libraries, and preference pages will be in scope. Interfaces for publishing and rendering the final document are also in scope, but may not necessarily make it into the first release.

As always, scope can change based on community and adopter feedback.

Perspectives and Views

The following are the additional Perspectives and Views that may be provided:

• Document Perspective - provides a separate view that is focused on items that are of interest to document authors.
• The primary views are the Navigator/Project Explorer, Outline, and Properties views.

Extension Points

Additional functionality and extension points allows adopters, to contribute predefined stylsheets and configurations for the editor.

Note: Information comes from the VEX information on extensions. http://vex.sourceforge.net/userguide/html/concepts/extending.html.

While Vex supports common document types such as DocBook and XHTML out-of-the-box, you can also extend Vex with your own DTD files and CSS stylesheets.

The first step to extending Vex is to create a plug-in project. Once this is done, you can copy the DTD and CSS files you wish into the plug-in project. Finally, you must provide a little more information to Vex by setting properties on the new DTD and CSS files. Note that you must provide both a DTD and a CSS file to be able to edit documents of the given type. The extension point mechanism allows Adopters to provide canned stylyesheets and grammars.

Users should also be able to extend the plugin via Preference settings, to add additional grammars and CSS stylesheets.

Project Organization

We propose this project should be undertaken as an incubator project with the Web Tools project.

Mentors

Possible Mentors:

• Ed Burnette - Eclipse Platform UI Committer
• Nitin Dahyabhai - WTP Source Editing Lead

Committers

• Ed Burnette - VEX committer - Developer at SAS, author of several computer books, and tech blogger.
• David Carver (XSL Tools Committer) - David is an XML Data Architect at Standards for Technology in Automotive Retail. He is also an eclipse committer on the XSL Tools project.
• Doug Satchwell (XSL Tools Committer) - lead developer on the Eclipse XSL Tools project and owner of Chase Technology. Doug developed the SSE validator for XSL Tools, and so would be able to help out with that on this project. He would also be keen to integrate libraries such as Apache FOP with the XSL Tools transform launches.

Initial Code Contribution

The initial code contribution comes from the sourceforge project, Visual Editor for XML.

Licensing and Intellectual property

All code is being relicensed under the terms of the Eclipse Public License. All committers have agreed to these relicensing terms.

Interested Parties

• Standards for Technogoy in Automotive Retail is interested in adopting a potential Visual XML Editor. This would provide a more users friendly mode of working with Docbook related files.

User community

Vex offers a wide range of potential application areas, for example:

• Document authoring side: Vex has the ability to edit Docbook and DITA files in a WYSIWYG editing mode, and already has a large user community
• Editor for XML files required in Eclipse projects, for example the Eclipse standardized project plan format
• Creation of Eclipse corner articles
• Corpus Linguistics: Manual enrichment of a text database (= corpus) with linguistic information (e.g. used in the ICE Nigeria project)
• ...other application areas editing XML-based (i.e. Open Office XML or Open Document Text) documents...

Tentative Development plan

The tentative plan is to get the existing code migrated and aligned with the Eclipse Development Process. This means that the code must go through the eclipse IP reveiw process. Once approval is given, the project can start to migrate functionality.

• Create UI and Core plugins.
• Integrate source views to leverage existing SSE editing and XML functionality.
• Update and create documentation.
• Provide base line Cookbook examples for creating appropriate stylesheets.

All of this will probably take 3 to 6 months to get in place. Additional information will be based on user community, and adopter feedback.

Relation to other Eclipse projects and other open source projects

• XSL Tools (incubator) - the output of the XML can be run through XSL Tools stylesheets for transformations into HTML, PDF, or other dita or docbook formats.
• DITA Open Toolkit - http://dita-ot.sourceforge.net/ - Output can be run through the DITA open toolkit to generate HTML, PDF or other dita support formats.
• DocBook Project - http://docbook.sourceforge.net/ - Maintains a set of stylesheets that can be used to generate the final documentation.
• Target Management: Remote System Explorer - provides framework for FTP, WebDav, and other remote file systems integreated into the IDE.