Reflecting on Stefano's RT's:
I guess there is not much doubt and argument about the "user agent <- publishing <- store" part as C2 provides an excellent framework for any type of contract implementation, moreover, as long as you have structured/and semanitic data in the "store", the rest of the job itself can be structured. The most dubious part to my mind is the "edit agent -> CMS" and the agent itself. The _dilemma_ lies in enforcing the user's input as semantically reasonable data, without losing the WYSIWYG traditions of the nowadays document management. A year and a half ago we were considering alternatives of making a CMS - a management layer for the new web-publishing opportunities C1 had opened. At rthat time we came up with three reasonable posibilities for the "editing agent -> cms" implementation: 1) java applet 2) mozilla XUL 3) IE "endowed" DHTML editor solution with the same good C1 for producing the structured input UI. Eventually we chose no 3) - as mozilla was _not at all_ popular in our user environment and IE had better integration posibilities with the _oh so popular_ MS Office. Another "PRO" was using the same C1 not only for publishing but also for producing the semantically "correct" DHTML-based UI and enforcing the logics of input that would afterwards be used by C1 in publishing - I hope you can trace a sense logics here ;-) Despite the fact that our goal was more about proof-of-technology, we implemented this solution and it is used for production in several places for more than half a year already. During that half of year I realised the shortcomings of such approach that can be divided to several areas of concern: 1) Users; office workers - people responsible for certain processes in the company and now able to directly report them by CMS. Despite the sophisticated and very user-friendly UI that we managed to develop (almost anything can be drag-n-droped anywhere; when creating content, managing permissions, creating new datasources, various items, etc), using any new wroking environment for the avg. office worker requires training and assistance. The axiom here is that training/teaching/assistance is always more expensive than development, especially for big companies, at which such tools are mainly targeting. 2) Integration with the existing CMS tools "on the desktop" (offices, like MS, Star, Lotus, etc) Remember the _dilemma_ - the more the solution is convenient for the developer (structured/semantic input approach discussed by Stefano) the harder it is to integrate with the existing office tools, which are primarily concerned about the layout of the document, not the structure. And suck office tools are not likely to die away so fast, sad but true. 3) New publishing/CM routine Going back to the users. A new publishing/content management environment creates a new/and different work routine that is additional to the existing ones. Generally, people are not satisfied having to work more than they used to. 3) Transformation of existing data Almost every company has a web site and some sort of document management system right now. A concern when considering editor agent for a CMS is whether/and how it will be able to handle the existing data, especially that is in a unstructured format. Well I guess this comes back to the integration issue. Considering these factors it seems reasonable to support Michael's proposal - using OpenOffice (OO) as an editor agent. In addition to the PROS that Stefano has mentioned (open-source, almost finished and portable) it solves (or is closer to solving) the integration (2) issues - by supporting the widely used proprietary document formats as .doc, .xls and a possibility to convert them to XML. I completely agree that the XML support the OpenOffice has to offer is a complete crap (looks similar to the html saved by MS Word ;-) but IMHO it is reasonable to try to enforce fixed templates in order to make the input more structured (and there is a chance that the OO guys might realize their mistake and improve the xml features just like MS did with their HTMLFilter2 ;-) While using to export the documents to the CMS the publishing routine (3) would remain the same as it was + one more "Save As" to be pressed to export the content to the CMS; and that would also decrease the training cost of the personel, thus increase the value of the product, right? Stefano's proposal is more appealing technologically (I was always fond of XUL idea for a front-end ;-) - I wanted to share a more managerial perspective. Anyway - both of these perspectives _should_ definately be the areas of our overlapping concerns in order to continue the trend of cocoon's success ;-) Regards, Alfredas ---------------------------------------------------------------- Stockholm School of Economics in Riga <http://www.sseriga,edu.lv> Strelnieku 4a, Riga, LV-1010 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
