[Zope3-dev] Axe DTML Document

[Martijn Faassen]

Casey Duncan wrote:
[snip definition issues, which are never perfect, as even the web itself
could be considered a document]

Sure, though I can't just 'read' the entire web, let alone 'edit' it,
and I can do so with a document. A Document is whatever people can treat
as one. :) But of course these definitions won't ever be perfect.

> What has come out here, which has pulled my head away
> from the forest, so as to see the trees, is that we
> are not defining a meta type or a class really for a
> document. We are defining an interface to which all
> documentish things can implement.

Yes, or probably more likely a set of interfaces. And some classes that
already implement the interfaces. I can imagine most documents can just
reuse the metadata object for instance, though some way want to override
it as they can get some of the metadata from other sources already and
fulfill the interface like that.

> So let's not quibble about symantics. Martijn, you've
> got yourself some pretty fancy ideas about what
> content is. Lalo has a different perspective. I just
> want some consistency whether the thing is fancy or
> not.

Of course; interfaces are definitely a key, and if I may invoke the Zope3
gods, "a Zope3 kind of thing". :)

> Lets define the interface for a basic piece of
> "content": living, DOMish, blobish or Amish. From
> there we can derive the dumb-as-a-stump File object,
> for all those fine "representative" "document" types.
> And then look at how we can extend it to best embody
> structured DOMish content. 
> 
> To me those are almost "Meta Documents". XML is really
> just a representation of the stored DOM structure, a
> view if you will. The fact that you can losslessly
> convert between XML and the internal structure is the
> key. So a user can think if it as a document, when in
> fact it is much more than that, it is more like a mini
> database in and of itself.

Though I feel this can be left for later (and flesh out the supporting
infrastructure interfaces first), we can also define some
standard interfaces for document representation. I don't know if we can
do a one-interface-fits-all approach here; DOM may be a good start but
won't fit flat textish content, which we'll want to support too.

> Now Martjin may feel that no one should "store" html
> as such (or at least they should avoid it). I would
> agree in principle, but in practice people will
> generate content using tools that output HTML thinking
> they are doing it the "web way".

Oh, that's my point; our framework shouldn't stop people from storing
HTML directly, if they insist on doing so. It's just we can't provide a 
proper DOM interface for HTML either, so there goes interface universality
for that area of the document framework.

> OTOH, If Zope 3 can easily create an environment where
> storing content in HTML, although wholly supported, is
> clearly not the best course, then everyone will win.
> Because the less enlightened will, by following the
> path of least resistance, at least in theory gain
> enlightenment. 

I agree. I was never suggesting we should forbid HTML content, even though
I wouldn't be using it much. :)

[snip]
> We're never going to define "content" let alone
> "document" adequately for everyone, so let's quit now.

My main objection was that it seemed as if we were trying to do exactly
that, and I think we should keep things more open than that. Of course we will
need to do some abstracting anyway.

> Let's just define an interface first for the simplest
> kinds of content objects (since that's easier) and
> build from there.

Agreed. I'll try to flesh out some dummy interface and post 'm.

Regards,

Martijn