[Zope3-dev] Axe DTML Document

[Lalo Martins]

On Thu, Dec 20, 2001 at 01:38:54AM +0100, Martijn Faassen wrote:
> 
> I use the words representation and presentation quite differently, and
> you seem to be able to interchange them more easily, so perhaps this gives rise
> to some confusion?

There is, of course, one "internal representation". Otherwise,
representation is a special case of presentation - an editable
form of the document, if possible lossless.

> > 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.
> 
> I still think you'd be confusing people if ZDocXML was the only valid
> 'Document' in Zope. Let's call a ZDocXML document a ZDocXML document. :)
> Other people will want other styles of document, and they can make
> legitimate claims to the Document word. If you assume Documents == 
> ZDocXML Documents you'd confuse people, including me. :)

The point I'm trying to defend is that the user shouldn't care
about the internal representation of a document - as long as it
supports a representation the user is comfortable with.

Kind of like interfaces and adapters in the component architeture.

> > Representation is, in this aspect, a special case of
> > presentation, as far as the component architeture is concerned.
> 
> I disagree -- you can never devise a document type that can somehow
> magically include all the possible things you'd want to include. 
> Now we have <person>, but tomorrow I may want <date> and the next day
> I may want <starship>, whatever. You can't get from a common representation
> what you don't put in in the first place; that'd take either a human to
> guess, a human equivalent AI to do the same, or magic. :)

I'm having trouble finding time to write the proposal (you know,
work). But to preview it, two words: XML namespaces.

> Anyway, this is why we should have a framework that does take care
> of the many commonalities, but doesn't fix on one or a few types of
> representation.

Yes. That's what I'm trying to achieve, but with a different
approach, because I also don't want to expose the representation.

> > Perhaps. I still think a transparent internal representation is
> > the best foundation.
> 
> Well, you'd lose me right away if you picked that as the foundation; your
> document would be useless to many of the applications I'm developing,
> which would be a shame.

Why? "Transparency" is a design decision that shouldn't affect
your application at all - the only thing you should care about
is "does it support what I want to do".

> > No. Please. Don't expose the internals.
> 
> So what do you do if people want to place HTML content? Or
> plain text for that matter?

Then they need to be educated on the fact that "HTML content" is
not really content, but one possible representation of a
DOM-like content :-)

> In order to do many useful things with documents, you need access to the
> representation. This doesn't mean we can't still build layers of
> abstraction; we should. But the internal representation is in many
> cases not dirty or ugly or 'internal' at all; it's semantic information
> that can be used by applications. It's in fact exactly what documents are
> all about -- their contents!

So you prefer to deal with C pointers than Python lists?
}:-)

[]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/