[Zope3-dev] Axe DTML Document

[Lalo Martins]

All right, now I get it.

On Wed, Dec 19, 2001 at 04:15:42AM +0100, Martijn Faassen wrote:
> Oh, you're discussing the 90% catchall document that will be delivered
> with the document _framework_ then. That's fine with me, but I think
> a framework is important. I want to do more with documents than just simply
> read them. 

Cool.

(Obs. - read *and edit*)

> > 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.
> 
> So you're saying DocBook documents aren't documents? What about PDF
> documents?

Yes. DocBook and PDF are representations.

> What about something almost representable by StructuredText
> *except* you want to mark up persons for some reason?

That's another point - the one I hadn't seen before your message.

> You'd be confusing people if you only accepted the 'can be represented
> as structured text' as a document.

I'm talking about an hypothetical StructuredText which makes
better use of the DOM capabilities - perhaps
reStructuredText. To avoid confusion, let's switch it for an
hypothetical ZDocXML format.

> > A "Person" is not a "Document".
> 
> A person can occur inside a document. Like such:
> 
> <header>Chapter Foo, the Marking Up</header>
>    
> <p>Hello, this is a nice paragraph containing some text. 
> <person>Martijn</person> is a person.</p>

All right. I have a proposal. But wait, you have more points :-)

> > > Why not build a toolset to work with different types of representation?
> > 
> > Because (re)presentation is outside the document domain.
> 
> *representation* is not outside the document domain at all! Presentation
> may be, but that's an entirely different concept.

No. Representation is, in this aspect, a special case of
presentation, as far as the component architeture is concerned.

Ideally, you should be able to change your Document component
for another one that has a different internal representation and
not notice it in your code - perhaps I should have said that
representation is outside the domain of IDocument, to be precise.

> A document contains textual content that is generally read by humans. A
> document can however also be processed by computers, which is why we
> put them inside a machine in the first place. By having a good
> computer-accessible representation of your document content you can
> improve things like annotation, linking and searching abilities; you
> can probably also increase the ways in which you present the document to
> users.

And you can also, by choosing a good representation, provide the
capability of rendering it in a miryad of other representations,
so that annotating, linking, searching etc. components that work
only with html, docbook, pdf, stx, or whatever can parse it.

> Documents are also generally written and edited by humans. Documents are
> commonly published, and therefore need a review procedure. Generally 
> documents have some common metadata as well. Documents do not necessarily
> have the same internal representation, however.
> 
> Why not capture the commonalities in a framework? It doesn't have to be
> perfect and extensible the first time around, but I suggest we at least
> try. :)

Perhaps. I still think a transparent internal representation is
the best foundation.

> Well, rename Document to StructuredTextDocument (or whatever is decided
> it can contain) and have it share an interface IDocument with all Documents,
> and I'd be happier. We could offer a PlainTextDocument and even a HTMLDocument
> as well (even though I'd generally not use the latter for anything serious).

No. Please. Don't expose the internals.

> > [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".
> 
> I'm not underestimating structured text at all, and I have a simple
> slideshow component for Zope on my harddrive that exploits the DOM-like
> properties of StructuredText. I think there are some limitations to
> structured text, however. reStructuredText is a project to fix what in
> their view are such limitations:

Right, sorry. Some obscure part of my mind probably thought
those features were already implemented.

> You and I like plain text (and I use emacs instead of a word processor to
> edit my documents), but not everybody can do this. This is one reason
> I'm suggesting a Zope3 document framework should contain interfaces
> supporting custom editors ('give me the default editor for this
> document' and such).

This is (IMHO) exposing implementation. I'd prefer "give me an
editor for this document, that doesn't lose any metadata" for
the picky, and "give me this document in format FOO" for the
tolerant. (Of course, this raises the problem of dealing with
lossy conversions, but I believe we're smart enough to find a
solution for this.)

Oops. This is too big. I'll post the proposal in a different message.

[]s,
                                               |alo
                                               +----
--
  It doesn't bother me that people say things like
   "you'll never get anywhere with this attitude".
   In a few decades, it will make a good paragraph
      in my biography. You know, for a laugh.
--
http://www.laranja.org/                mailto:lalo@laranja.org
         pgp key: http://www.laranja.org/pessoal/pgp

Brazil of Darkness (RPG)      ---       http://www.BroDar.org/