[Zope3-dev] Axe DTML Document

[Martijn Faassen]

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. One of the most important points about using
XML for documents is that people recognized you can't store all document
types in one and the same format. Instead, with XML, we try to abstract to 
a common base as much as we can (XML markup and all the standards on top 
of it), but we don't standardize on one single schema for all XML.

Similarly, any Zope Document framework should recognize this as well and
allow many types of documents to work together harmoniously.

> Then, when you want to edit it, you request the format with
> which you are comfortable - HTML, StructuredText, ZDoc-XML
> (hypothetical), or whatever you have Adapters to generate (and
> parse).

While adapters certainly have a place in documents, it's just not
possible to have such a universal underlying representation and adapt
to it always; such a representation can't contain enough information to
satisfy everyone's requirements, and the requirements that it will satisfy
will be insufficient for any sophisticated document management system.
(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) 

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

> For the few remaining cases, someone will develop different
> components soon enough ;-)

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.
Why not build a toolset to work with different types of representation?
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).

Regards,

Martijn