Michael Hartle wrote:
>> 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. The problem is that it's not the same information that goes back and forth between OO and, say, Docbook. When you convert OO to Docbook, given some (hard) guessing you can almost manage to have something that works: take the formatting informations out of the way and assume that the author used styles in the (agreed, not imposed so easy to circumvent) way. When you go the other way around there is no guessing that can be done: you have to invent a bunch of informations that aren't present in the document itself so in the best scenario you'll end up hardcoding values. Note: if this was to be done for a customer project, I'd be happy to follow this path: actually, if using OO was part of the given spec, I wouldn't even bother, I'd just write a couple of Cocoon components, a bunch of stylesheets and I'd store the .sxw files directly in the store, possibly with a small metadata DB. But given that we're working on frameworks I fear that we are starting to enter an implementation domain, thus limiting the power of the generic framework (remember that it's always the weakest link that gives you the benchmark for the flexibility of your framework: in this case you wouldn't end up with a framework but with a CMS for Open Office). > 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. I share your feelings and RL experience on that. Unfortunately, this is the way to go, at least for now. But let's not forget to pave the way for real semantic-enriched tools. > 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) Unfortunately this is another case where the dumbness of Serializers is acting as a major inconvenience: given that Serializers don't have a clue about the environment I think you would have an hard time using them in this scenario. > 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. Good point, but this means once again that I'm right in stating that Cocoon can be used to make a CMS, not that a CMS should be built inside Cocoon. > 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) Sure thing, I'd like that too. This is why I'm digging into the ODK lately: but once again this is an implementation domain problem, it has little or nothing to do with general Cocoon development. Ciao, -- Gianugo Rabellino --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
