cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Integrating Cocoon with WebDAV
Date Tue, 06 Nov 2001 10:52:39 GMT
Michael Hartle wrote:

First, let me express something that I think you got wrong: I believe
the OO solution is a hack, but I definately agree it would be a good
migration path for people enter the semantic world and I'll be very to
support that on Cocoon (even if not with personal direct development on
my part).

This said, read my comments below.
 
> 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.

In my personal experience, Word users don't understand styles and don't
care about the structure of the document (they edit in the fully WYSIWYG
view, not in the structure view).

This will *always* result in users messing around with the document
structure, no matter how hard you try to force them not to do it.

Word is freeform, no way around it.

OO Writer is slightly more structured (I wrote my thesis on it and,
believe me, it's lightyears ahead of Word on more structured document
editing!!) but still not really into "semantics" (although I agree that
with a few new features, it could be just good enough for many uses,
expecially semi-structured content like books or articles).
 
> >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.

Well, believe me, I know what you mean :)
 
> 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.

Very reasonable view. Believe me, I'm 100% with you on this.
 
> >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.

Cool, I there is full agreement on that on this list and this is very
good: it must be the best way then.
 
> >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.

Good point. We are definately talking about two different "groups" of
users: the one you are focusing on is able to use Word, to organize its
content and have enough abstraction to see the picture in their minds.

Believe me, this is nothing but a strict minority of the people out
there, even those already working with Word today on an regular basis.
 
> 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.

Now, here I disagree. The location of content (where) is one of the
contracts between the publishing system (PS) and the CMS. The PS is
requested with something and makes an effort to provide the content
(what), then it must know how to do the mapping between "what" and
"where".

This mapping might be "soft" (say, a search), or "hard" (say, a XQL
query, or an XPath query or an HTTP request to a specific URI of the
CMS), but most of the time the PS expect "hard" linking between
resources.

Now, suppose the PS sends an XQL query that expects some internal CMS
layout, but the editor has WebDAV access to that layout and decides,
arbitrarly, to change create a new folder for her content because she
likes it more that way. Bang, the content is not published anymore,
unless somebody updates the XQL on the publishing side.

Sure, we could have more than one mapping inside the CMS and allow
editors to store their files wherever they want, but then they *have* to
edit a list of locations that maps every location meaningful to the PS
to the document places into the CMS. A clear mess! and a clear point of
failure of the system!

So, sorry, but I don't see the "disk" metaphore as nothing else but
asking for troubles.
 
> 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. 

Here, you are assuming that what the PS does is a simple one-2-one
mapping between the folder and the URI space. Please understand this is
not the case in general, but it's just a very specific example of use.

We cannot base our design on something which is a very specific example.

> 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. 

Oh, here I agree, but then again, such a CMS must provide a way to
"force" people to save their stuff in a very specific location. No way
around this.

> 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.

Correct.
 
> I do not believe that directly integrating a CMS into Cocoon itself is a
> good and healthy thing, as it removes choices of combination. 

Yep.

> 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.

Go for it, I fully share your vision! but be careful about giving too
much power to your editors.
 
> >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.

Oh, no, it's way more powerful than that. Look at mozilla's built-in
mail client: the user interface is built using XUL and XBL. Now, would
you call that "textfields and the like"? I personally wouldn't.

> 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.

We are clearly talking about two different user groups: I'm talking
about the secretary that has to update the news on the homepage or the
car dealer who has to update his website with the new cars that arrived,
up to the people entering newsfeeds by hand, or highly structured
content.

You are talking about creative editors who write articles or
documentation or books or stuff like that and require more powerful
tools and can stand more rope without hanging themselves with it.

There is also a third user group who hates WYSIWIG and wants to edit
directly into the source to have full visibility on what the editor does
(believe me, even good web designers can't stand FrontPage or
DreamWeaver for HTML creation!)

All three user group exists and sometimes even the same person might be
in the three different groups depending on what he has to do.

Me, for example: I want "NO FREEDOM" if I have to edit content in a
system I don't know nor I want to. I want "ENOUGH FREEDOM" if I have
different editing choices but still want some structure to help me (say,
when writing a book or an article). I want "FULL FREEDOM" when I'm
designing a system or doing wild stuff.

So, my idea is: let's have tools that support all three kinds of work
because I might need myself to use all three.

> >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.

Bah, this doesn't stop me if what I'm looking for is not already there.
See XSP, for example.

> What about the pure XML/CSS approach where there are already usable
> standards and open source implementations ?

??? what the heck is a "pure XML/CSS approach"? I'm suppose to drive a
user interface, not to present some information. Sure, where possible
I'll be using existing XML languages as internal namespaces or existing
technologies like CSS.

> (Batik contains a CSS parser)

So? Mozilla already does.

> This would allow semantic attributes in a WYSIWYG environment,
> but it would still lack the infrastructure an Office implementation
> could provide.

I don't necessarely agree on this, but the group of users who are going
to use this can't probably care less about an office infrastructure.
 
> 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 ?

Because OO needs changes in the core, something that not even
export/import filters can do.

I mean: if the user has the freedom to change the font size in the style
or even add his own styles or change the styles name, how the hell I'm
going to write an export filter to "know" what he wanted to do with that
and how to map this to a semantic markup language?

> 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. 

Thanks for reminding me how open communities work and what benefits they
provide me.

Anyway, it's good that we have different goals and focus on different
usage types so that we can cover the most possible ground and embrace
the biggest number of users and use cases.

I think this is a good thing. And let me restate: the fact that I'll be
focusing on the first group (even because I might earn some money out of
that, and, you know, this helps when you are unemployed) should not stop
you from focusing on some other group or some other solution.

All I ask is to keep on working together to reduce possible overlap and
design a system which is as coherent as possible.

Good thread, yes, definately a good thread.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message