Stefano Mazzocchi wrote: >One proposed solution (Michael's), is to use > > CMS -> Cocoon > edit agent -> OpenOffice > >which has several PROs and several CONs. > >PROS: > > 1) much is already written (which is not bad :) > 2) fully portable > 3) fully open source > >CONS: > > 1) OpenOffice XML format is ultimately useless being nothing semantic >but ultimately presentation driven. I has more or less the same semantic >content that M$ Word spitting HTML and Gianugo is perfectly right when >he says that do it back/forward a few times and you're screwed. > This requires us to design the transformation from our content xml format (like DocBook, which you prefer) to OpenOffice and back in a way that this will not happen. The consequence of this might be that we cannot "map and reverse" each element and attribute, but we definitely get the most out of it.
Matt Sergeant (http://www.xml.com/pub/a/2001/02/07/openoffice.html?page=1, http://lists.oasis-open.org/archives/docbook-apps/200102/msg00038.html) has shown a way from OO to DocBook that may not be perfect, but a start; he also makes some good points on requirements that clients tend to make. >If you want my personal opinion: this is a dead end. OpenOffice (just >like office!) suffers from WYSIWYG syndrome and it's inherently useless. >It sucks that so many millions of lines of good code are nothing useful >for us, but hey, this is so for many other things, so no biggy. > Millions of users are accustumed to Office environments and the resulting non-semantical approach to work. Blame it on Microsoft or someone else, but there are hundreds of thousands of users who still use tabs where tables would be appropriate. I recently had a meeting where it took more than 10 minutes to make others understand the difference between semantic and non-semantic. The problem is not whether or not this may be a dead end in the very long run (which I do not believe and even in case, I then would describe it as viable legacy support), but what a solution requires, what users are accustomed to and what they are willing to accept. I made the experience the hard way that the latter two are critical, and with corporate players that are affraid of radical changes to semantic approaches, this will stay this way some time. >2) Some might think that the "arrow of time" of the cocoon pipelines >are inherently biased outward (I don't believe so, but anyway) and >adding webdav capabilities might ruin the elegant internal design. > >Personally, I think that once the flowmap is in place and we have a >better way to indicate flow between resources and between different HTTP >actions on the same resource, then most problems will be cleared even on >this side, but for now things remain. > I came to the result that to protect the investment in current component categories like Generators and Serializers is the best choice available at the moment, as they will still be around when flowmaps are available (hopefully I understood it right and thats the case) >1) CMS because Cocoon shouldn't implement CMS stuff but should simply >"use it". Things like user management, locking, revisioning, metadata, >scheduling and all that should be a layer built around the storage. The >contract between CMS and cocoon being some API or some avalon behavioral >services. > I like this part definitely; it matches my understanding and vision of Cocoon as a representation layer for things like Batik, FOP and CMSs. >At the same time, content editors don't give a shit about "where" >resources are located and I disagree vehemently with Gianugo when he >says that you have to give them the harddisk methaphor otherwise they >are screwed. > >Well, they would be anyway: in fact, when they approach an editing >system, they don't ask the question "where", but "what". The translation >between "what content to modify" and "where to save it", mixes concerns. > >Result: the disk metaphore (so well used into almost all operating >systems, but *NOT* the web!) forces editors to know where to place >things and they don't care. (many thanks to Laura, my girlfriend, for >opening my eyes on this!) > I really do not believe that is the case. Perhaps an editor who just creates or edits contents once in a while may show no interest in the way contents are organized (the "where"), but the majority of editors is working regularly on certain areas that they are assigned to, and they will definitely participate in the way content is organized. The disk metaphore instead gives a fast start and "forces" editors to know what they create and edit; making the appearing(!) disk layout for each editor customizable gives him/her the opportunity to modify his view(!) according to his preference and work style. The central storage in a CMS, for example, is not affected by this. That is what Cocoon is about in my eyes; transforming content to deliver certain views on content. What a user sees when looking into a WebDAV folder strongly reminds me of such a view. When a user loads and saves content from a WebDAV folder, he is interacting with such a view like a person using a form on a web page. I do not talk about turning Cocoon into a CMS, but to enable Cocoon to provide views to a new, interactive component like a CMS. Adaptors to various CMSs would just be another brick in the wall like Batik or FOP; Cocoon does not produce PDFs or JPGs itself, but it hands through the task. I do not believe that directly integrating a CMS into Cocoon itself is a good and healthy thing, as it removes choices of combination. But Cocoon works perfectly as a layer to map requests to virtual/real resources that may have needed some transformation, and I want that power to assist me when I target WebDAV usage. >So, what would be the best editing system for a content writer? > >Log into the editing virtual host, ask what content to add, modify, >approve, change, schedule, and what not and have the CMS give you a page >that allows you to "edit" it in place. > >How so? A XUL-powered mozilla IDE that integrates skeleton-based >in-place editing capabilities. > If I understood the skeleton-based in-place editing capabilities correctly, it goes into the direction of forms, textfields and the like. One thing is for sure, writers hate writing content in a solely skeleton-based environment as it gives you absolutely no chance of semantical flow-text attributation (something that can yet be achieved in the OpenOffice direction in the future). I saw products that tried to solve this problem in a skeleton-based manner and failed in the eyes of users. Something writers will hate, too, is that you do not have the support of spell-checkers, file import/export filters and the like, which are available in either OO or Suns extended StarOffice. >What is that? Ok, assume you have a news item like this: > > <news title="..."> > <picture href="..."/> > <text> > <p>sdfljskdfj<strong>lskdjflk</strong></p> > </text> > </news> > >then we can get the schema of this and transform it into a markup that >indicates the structure but also the visual information required for a >client to present a "semantically-WYSIWYG" interface. > >So, Mozilla is my choice, but it could also be implemented as a java >applet, or java application that reads this information, prepares the >skeleton, fills with existing content and guides your editing >experience. > >Then it saves using WebDAV. > >I think mozilla could allow us to use all the CSS capabilities to >implement easily the skeleton and graphic placement, and also be >completely portable across systems. (yes, editors will be forced to use >Mozilla, but I see nothing wrong in that :) nor a limitation of their >effectiveness. > >In short, such yet-to-be-written "Structure Skeleton Description >Language" (SSDL) should be the driver of the editing experience and the > I do not have a good feeling regarding this approach; there is already an inflation of (.*)(D|L)L languages around. What about the pure XML/CSS approach where there are already usable standards and open source implementations ? (Batik contains a CSS parser). This would allow semantic attributes in a WYSIWYG environment, but it would still lack the infrastructure an Office implementation could provide. If you are willing to walk this far into the direction of pure semantically-WYSIWYG to bring it to a public success, why not develop import/export filters or similar OO components ? You would benefit from an established infrastructure and adding it into a well known product where you do not have to do all the documentation and training for yourself when it is being used by a client. (http://xml.openoffice.org/, http://xml.openoffice.org/xml_specification_draft.pdf) Best regards, Michael Hartle, Hartle & Klug GbR --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
