- From: <Marco.Hoedtke@t-systems.com>
- Date: Wed, 4 Jan 2012 15:18:59 +0100
- To: <www-amaya@w3.org>
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