[Zope3-dev] Axe DTML Document

[Lalo Martins]

On Tue, Dec 18, 2001 at 09:29:31PM +0100, Martijn Faassen wrote:
> Lalo Martins wrote:
> [snip]
> > Ideally, this Ideal Document component would store its text in one
> > single, simple format - StructuredText or some kind of XML.
> 
> This is completely impossible, however -- I may want to use one type
> of XML and you may want to use another, while the guy next door wants
> to use reStructuredText.

Why? And why not just convert (adapt) it?

We're talking about "documents" here - meaning, any content body
not complex enough to justify its own component class. So, I
advocate that, yes, it should be a very simple and single
format, bacause if you can't represent your data in, say,
StructuredText, then it's *NOT* a Document, but a component
deserving its own class.

One of the goals of Zope3 is to make it easier for you to have
your own component classes (like ZClasses should have done for
Zope2, only better).

> (try searching for, say, persons, if you have no way to indicate what a 
> person is in your underlying representation. Or think of advanced 
> hyperlinking) 

A "Person" is not a "Document".

> > Most situations where this is not OK are really mixing content
> > and presentation.
> 
> That is in my opinion not correct. In many cases you deal with types of
> documents that have domain-specific requirements, and this has nothing to 
> do with mixing content and presentation. For instance, currently I'm
> dealing with various university publications, but also with summaries of the
> Dutch republic's State General meetings in 1625, and am also looking into
> biographical descriptions. 

And what is the problem? Do they *require* more complex markup?
Or do they just have some of their own metadata?

I think a very complex Document component leads to abuse. This
simple "Document" component should *NOT*, I repeat, be used for
things that should instead be their own component classes.

> I agree that for a lot of documents a fairly simple representation such 
> as StructuredText is enough. But I also believe that trying to fit
> *everything* into one single representation wouldn't work at all.

Not everything. Just everything that is simple enough.

> Why not build a toolset to work with different types of representation?

Because (re)presentation is outside the document domain.

> That doesn't stop you from creating a simple document type that is
> good enough for many purposes, but at least nobody would be forced to
> work around it (or with it while they shouldn't as their content model is
> too different).

I'm not proposing a single component that will from now on be
used for all Zope3 content. By all means. Content components are
even their own category and treated with special care in the
documentation. I *WANT* people to develop hundreds of these
classes.

So, what is the purpose and place of a generic "Document"
component in this world?

The way I see it, a component for data that is too simple, or
a temporary holder for data you're beginning to work with - you
store your meeting summaries in a Folderful of Documents, then
you work with them for some days and gather notes on the
requiremens for their own class - and then you go and develop
that class.

Perhaps Document could even have some facility to convert itself
to some other class?

[verging off-topic]

Also, don't understimate StructuredText. StxNG is more
"structured" than "text" and can hold up pretty much anything -
it's almost a "very very very light, human-readable XML". The
fact that we use it with some very defined rules to render to
HTML is an historical artifact of habit, but remember that the
Zope Book is also written in stx and converted to a lot of
formats using different rules.

Lalo