W3C home > Mailing lists > Public > www-amaya@w3.org > January to March 2012

AW: Amaya design

From: <Marco.Hoedtke@t-systems.com>
Date: Wed, 4 Jan 2012 15:18:59 +0100
To: <www-amaya@w3.org>
Message-ID: <ADBC8EB79100024ABC6EDB2071794DF06882548B06@HE111509.emea1.cds.t-internal.com>
I have been using Amaya and following its development for about 6 years now. I think it is a unique XHTML-Editor, at least I have not found another free editor with the same features. So, obviously, I am strongly in favour of not letting it die. 

I would like to explain why I am finding it unique: It is because Amaya can be used as a front end to an XML-database. I am using the free XML-database eXist (www.exist-db.org) to store and retrieve project-documentation. By doing so, it is possible to use the complete range of XML-technology to retrieve and process these documents (xpath, xquery, xquery-update extension, xsl).

Via WebDAV Amaya can read and write directly from/into the database. There are other free editors which can access the XML-database via WebDAV (e. g. jedit), but not with WYSIWYG-features. 

With the couple Amaya/eXist a whole new concept of collective document creation and processing is possible. Maybe this would even make a good new open source project. Maybe some new specific features like for example xquery-support could be added to Amaya.

Best regards

Marco Hödtke

-----Ursprüngliche Nachricht-----
Von: Daniel Hernández [mailto:daniel@degu.cl] 
Gesendet: Mittwoch, 28. Dezember 2011 21:48
An: www-amaya@w3.org
Betreff: Re: Amaya design

Today some people convinced me that CompoZer is a good alternative to Amaya. I have take a check and a think that it is. Maybe is time to say bye Amaya.

On Wed, 2011-12-28 at 11:30 -0300, Daniel Hernández wrote:
> I think that for some uses Amaya is the best HTML document editor. The 
> advantage as HTML editor is that you can organize your documents in a 
> non hierarchical way, navigate across them or share it with other 
> people in the Web. That is better than editing single documents with 
> OpenOffice. But it have some problems related with its architecture.
> The first problem is that in the Web we don't see documents as the 
> building blocks for content. Even in content oriented CMS as Plone you 
> see the emphasis in portlets and viewlets. That means that building 
> blocks for sites are sub-documents that are combined and showed along 
> the site. Also pages have more functionalities. You can filter 
> documents by tags, select date ranges or find documents. That features 
> are completely necessary for web sites today.
> I have wrote some sites using Amaya and running some scripts to 
> reorganize documents, generate site structure and other thinks. Also I 
> mix the static pages with content generated dynamically for some 
> specific views. But it was to much work, and now I'm migrating sites 
> to Plone. Now that I'm writing some documents in Plone I note that I 
> really hate editing content in the Plone text editor and in any other web CMS.
> To edit documents Amaya is the best.
> Another interesting application to manage documents is Zim wiki. It is 
> a desktop wiki that you can use to edit notes (as with Tom Boy) or to 
> edit collaborative documentation using Bazar to manage versions and 
> merge branches. I think that there are a lot of features of Zim that 
> can be ported to Amaya. Some of them are:
> 1. Creating documents from links (as in a wiki).
> 2. Renaming or moving nodes updates all incoming references.
> 3. Attaching files also store that files.
> 4. Having several plugins.
> 5. Synchronization with versioning systems (now it only supports bzr).
> 6. Integrating several nodes in a same documentation project.
> I think that the most important difference between Amaya and other 
> tools to develop content is the point 6. Amaya is a page editor. Zim 
> and Plone are tools to develop sites. Today you need today a tool to 
> develop sites, that means to edit several documents as a whole.
> I haven't see the code, but maybe the second problem is its monolithic 
> architecture. It is necessary to get rid of the SVG editor for the core.
> We don't need to edit SVG in Amaya, we can do it in Inkscape, or other 
> featured SVG editor. Maybe that kind of features must be implemented 
> as plugins.
> I was experimenting with the Amaya template system, XTiger, and I have 
> proposed an alternative template system in my engineering thesis. But 
> now I think that we need tools to manage microformats in another Way.
> With XTiger microformats you have each document related with one 
> template. Now that you needs is to write objects inside documents and 
> that objects could be managed with several templates. This is the 
> point where templates compete with JavaScript. In the current Web lot 
> of content edition is made with JavaScript and server side processing. 
> The question is: Where to implement that features? in a editor as 
> Amaya or in JavaScript? You can implement several features of Amaya in 
> JavaScript delegating the problem of rendering the HTML to common 
> browsers, but in that case you lost the power to edit any document as 
> you like, because the editor will be set in documents. For me the question is open.
> --
> Daniel Hernández

Received on Wednesday, 4 January 2012 14:28:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:43 UTC