cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <gian...@rabellino.it>
Subject Re: [RT] Integrating Cocoon with WebDAV
Date Sun, 04 Nov 2001 14:06:30 GMT
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message