Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "WTP/VisualXMLEditor/Proposal"

< WTP
(Extendable)
(Extendable)
Line 39: Line 39:
  
 
- I think macros would be a bit ambitious. Eclipse doesn't even have that yet. --[[User:Ed.burnette.sas.com|Ed.burnette.sas.com]] 18:51, 29 August 2008 (UTC)
 
- I think macros would be a bit ambitious. Eclipse doesn't even have that yet. --[[User:Ed.burnette.sas.com|Ed.burnette.sas.com]] 18:51, 29 August 2008 (UTC)
 +
 
--- Agreed...this came from the original VEX Vision statement from the sourceforge site. - DAC 29 August 2008
 
--- Agreed...this came from the original VEX Vision statement from the sourceforge site. - DAC 29 August 2008
  

Revision as of 22:28, 29 August 2008

THIS IS A DRAFT PROPOSAL AND NOT AN OFFICAL WTP PROPOSAL YET.

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

- Can it be Visual Editor for XML (VEX)? I'd like to keep the Vex name if possible. --Ed.burnette.sas.com 18:51, 29 August 2008 (UTC) --- Sure, I've updated the proposal. -- DAC 29 August 2008

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.

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, and automated functionality should be possible using a built-in macro language. Document Editing.

- I think macros would be a bit ambitious. Eclipse doesn't even have that yet. --Ed.burnette.sas.com 18:51, 29 August 2008 (UTC)

--- Agreed...this came from the original VEX Vision statement from the sourceforge site. - DAC 29 August 2008

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, 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.

- One of my complaints about Vex is that you have to create a plug-in project to make a new document type. We should lift that restriction. --Ed.burnette.sas.com 18:51, 29 August 2008 (UTC)

Project Organization

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

Mentors

Possible Mentors:

  • David Williams - PMC Project lead for WTP
  • Ed Burnette - Eclipse Platform UI Committer
  • David Carver - XSL Tools committer


Committers

  • John Krasnay - VEX creator - need background
  • Ed Burnette - VEX committer - Developer at SAS, author of several computer books, and tech blogger.
  • John Austin - VEX committer - need background
  • David Carver (XSL Tooling Committer) - David is an XML Data Architect at Standards for Technology in Automotive Retail. He is also an eclipse committer on the XSL Tooling project.


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

Visual Editor for XML already has a large user community that covers mainly the document authoring side of the XML community. It already has the ability to edit Docbook and DITA files in a WYSIWYG editing mode. This also has other potential users from the eclipse community, particularly those that have to create the eclipse standardized project plan format, as the editor has the ability to visually edit any XML. Other XML document formats can be supported like Open Office XML, and Open Document Text. There is wide potential for this community to increase as potential with in the eclipse community.

With in Eclipse, Eclipse Corner articles could benefit from the visual XML editor project as it would provide a nice user friendly way to write and create eclipse corner articles.


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.

Copyright © Eclipse Foundation, Inc. All Rights Reserved.