> > Again, I think WebDAV access through Cocoon is more than worth the
> > effort.
>
> Definitely worth having, not clear how :-)
Uh, what a thread :)
Ok, let's try to summarize a little.
This is what I believe is a good chain for publishing:
user agent <- publishing <- store <- CMS <- edit agent
This is way general and the arrows represent contracts while the terms
represent concern islands. If you think about it, this is not even
releated to digital publishing: you could well apply this chain to
printed newspapers if the final user agent is requesting, say, a
PostScript version of the entire thing.
(in that case, the system publishes just one resource, the final
to-be-printed, newspaper).
In fact, such a system would be general enough to enpower almost all
publishing needs in the world (from the same content, it could serve a
printable PostScript version, an MPEG2 cnn-like overlay stream,
whatever), or I think it might.
Anyway, let's try to name the terms:
publishing -> cocoon
well, that was easy :)
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)
which is a native XML DB. IMO, it lacks a few features to turn it into
such a storage system (most notably, versioning, locking and a few other
things that things like CVS has), but it's a great place to start and a
great way for the publishing system to have access to the content (thru
XQL or the like).
We are left with the last two:
CMS ->
edit agent ->
Here is where almost everybody doesn't have a clue. But don't forget we
have another two contracts to define
store -> CMS
CMS -> edit agent
but we identified the last contract (at least the transport) with
WebDAV.
Ok, so, let's repicture the thing:
user agent <-(http)- cocoon <-(xql)- xindice <-(?)- ? <-(webdav)- ?
which leaves three big question marks.
The unknown contract will probably be filled by the xindice guys (XMLDB
API being the probably candidate, but maybe a JSR would add that
functionality into JDBC4, I don't know at this point, but I'm confident
that something will come out as soon as the xindice people (with us)
tackle the problem in detail).
Now, let's concentrate on the two missing pieces:
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.
Now, this said, there is a solution (if we convince the openoffice
people to implement it, but they already stated clearly that docbook is
nothing they care about): make template styles unmodifiable and fully
customizable.
I mean: we could end up with a template that includes most docbook tags
(O'Reilly does so with their book editors: they provide a word template
with a bunch of macros that mimic docbook) and make those styles
"read-only".
In this case, we can be sure that users don't mess with that.
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.
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.
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.
There are many other solutions (Gianugo, the living freshmeat, will
probably list a ton of them :) but here is what I think would be the
best solution (not carved in stone, but what I like the best so far)
user agent <- cocoon <- xindice <- CMS <- mozilla
Yes, mozilla. I'll explain why in a moment: please keep reading.
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.
2) Mozilla because of XUL and XBL. You'll understand why in a moment.
(note: this CMS might be Slide refactored, an extension of dbXML or some
other project, or might even contain parts of Cocoon for xml handling,
at this point, it doesn't really matter).
- o -
Ok, I think I shocked you enough with XUL and you need some information.
Let's take a step back.
Almost everybody on this thread admit that editing cocoon content from
the user-agent side it's bad, hard, algorithmically impossible and mixes
concerns.
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!)
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.
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
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.
(which is very close to what newspapers do today, anyway, but they are
much less flexible since these template skeletons are built into their
software)
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.
So, should webdav be integrated into Cocoon? well, at this point, it's
early to tell and it depends on the shape that the CMS part will take.
One thing in my mind is for sure: Cocoon shouldn't become a CMS, but
might well adapt the CMS API with the XUL-powered solution and, in that
case, it might require some WebDAV capabilities of some sort.
But again, this will make sense only after the flowmap is in place.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
