[Zope3-dev] Axe DTML Document

[Paul Everitt]

Casey Duncan wrote:

> There have been good points raised here by all. I think I will draft a 
> Fishbowl proposal on this sometime soon. Here is my take on what a "Document" 
> object would be:
> 
>   - The data/content would be textual and static. I doubt you could create a 
> single XML format to efficiently and effectively handle all cases, so likely 
> it would need to support whatever textual format you desired.
> 
>   - It would have the capability to add metadata/properties. Would the 
> ability to specify a common/default schema (dublin core?) be beneficial?
> 
>   - It would have History/diff capabilities perhaps like what DTML objects 
> have now, maybe better.
> 
>   - Supporting adapters would be created to do things such as HTML 
> decapitation, format conversion (STX -> HTML, HTML -> Raw Text, LaTEX -> 
> DocBook, whatever), metadata extraction, etc.
> 
>   - It would have some form of catalog or index awareness.
> 
>   - It would be available for 3 easy payments of $19.95 (No CODs, please)!
> 
> The document object itself will probably be dead simple and likely dumb as a 
> stump. Not much there beyond a file object. Actually, what IS the difference 
> between a document and a file, once you have ComponentArchitecture to 
> componentize the behavior?


Here's one: a Document has its contents full-text indexed, a File 
doesn't.  Whether that's correct behavior or not, I won't assert. :^)

I've gone through the responses and I'll summarize here some of my views.

1) There is a tension between making Document smart or dumb.  This 
corresponds to putting a lot or a little programming into Document.

2) I'm concerned about making the data in the ZODB future-proof.  If the 
class that the pickle is an instance of is overly rich, then you might 
find yourself always writing converters for every Zope upgrade.  Also, 
the data may be less usable outside of Zope.

3) I'm someone that uses CMF Documents quite aggressively.  I'm 
constantly trying to find some damn tool on some operating system that 
can replace a TEXTAREA w/o disappointing me.  Thus, in some ways I have 
expectations of my Zope3 folder appearing to be a fileserver, albeit one 
that can give me a bunch of extras when I look at it through a web 
browser.  This is an important usage.  It covers the majority of content 
currently being authored by the majority of average users.

4) In some ways, the smarts of CMF Document leads to unexpected behavior 
for (3).  For instance, say I'm using WebDrive/DavFS to edit a text 
document.  I save it.  It's immediately out-of-date, because the CMF 
sticks Dublin Core headers into it.  If you pick some neutral DOM 
representation, you're by definition changing the original in a perhaps 
lossy way.  Users might not expect that and give up when things don't 
work as expected.

5) OTOH, most of the value an organization gets is in turning raw data 
into repeatable, standardized content with rich services.  Pulling this 
off without alienating users (see (4)) is the trick.

I think this project should start with a proposal that captures all the 
questions first.  Then five or six of you go off and haggle about the 
answers.

Jeffrey, Herveline just told me to say hi to you.

--Paul