Stefano Mazzocchi wrote:
> This is what I believe is a good chain for publishing:
>
> user agent <- publishing <- store <- CMS <- edit agent
Almost agreed, but not totally. IMHO a better approach is:
user agent <- publishing <- CMS <- edit agent
|
store
The publishing engine should never pull content straight from the store,
it should rely on the CMS (the only one who knows about rules,
permissions, schedules and so on). But this is a minor issue, even if it
introduces a new contract to be defined between the CMS and the
publishing part. I'd suggest that a (pseudo-?)protocol is the best way
to go here.
> The second one is more tricky and not everyone agrees with that but I
> think it's a good move:
>
> store -> XIndice (formely known as dbXML)
+1 or better yet: *any* XML:DB compliant database. Note: I kinda
consider this a good compromise, since I'd better think that the CMS
should be "store agnostic" as much as possible, but yes, this can be a
good start.
> 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.
Unfortunately true. :(
> 2) Some might think that the "arrow of time" of the cocoon pipelines
> are inherently biased outward (I don't believe so, but anyway)
Neither do I, but given the current status it might turn out to be
confusing to say the least.
> 3) CMS provide a bunch of things that Cocoon doesn't currently provide
> and that must be implemented, but then, it would either have to rely on
> an external client, or provide a webapp that copes with those things.
Now the CMS part will be the trickiest one. I'm still convinced that it
can be done *with* Cocoon, but it shouldn't be done *by* Cocoon. Well...
I'm a Unix guy, I feel better with small cooperating systems, each one
performing very well one or two simple tasks. I fear a lot the
monolithic approach, so I would exercise caution before entering the
application domain within Cocoon itself. Anyway yes, it doesn't really
matter at this stage.
> 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... this is what they used to IRL. I'm all for studying new
approaches, but we shouldn't forget about editors and their computer
knowledge. Not to mention that the "in-place" editing (be it via Mozilla
or not) that you're suggesting has for sure a lot of PROs, but also a
lot of CONs, the first being the inability to operate in disconnected
mode, with user interface problems (I've seen so many web page editors,
even if I confess that I miss the power of Mozilla) coming as a good
second: wait until your writers will ask you for spelling checkers to
understand that you're in a dead end alley.
I'm still convinced that a writer knows about a word processor, this
being its instrument of choice. Of course she can learn to use another
metaphore, but this (which comes from real life experience) scares the
hell out of me. Anyone who tried to convince a team of writers to switch
from Word to Staroffice probably shares this feeling with me. I'd
rather keep the word processor metaphore whenever possible: not that I
like it, but they do.
> In short, such yet-to-be-written "Structure Skeleton Description
> Language" (SSDL) should be the driver of the editing experience and the
> client should be able to get a document, its schema and its associated
> SSDL skeleton and return a valid document, but allowing the editor to
> work in a "semantic WYSIWYG" experience.
Has anyone worked with the new (commercial) XML Spy web module? It seems
to do almost exactly what you're envisioning.
> Of course, the cons of this is that all the software has to be written
> and the SSDL language needs to be defined, but, hell, I'd like to code
> on a solution that lasts, rather than writing gluecode around hacks in
> order to avoid some more coding and end up throwing everything away in
> the future.
Enthusiastically +1 here, please enlighten the path and I'll follow you. :)
Ciao,
--
Gianugo Rabellino
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
