Chris McDonough <[EMAIL PROTECTED]> writes:

> I think the only good reasons we have right now for having
> filesystem-compatible serialization are to make Zope content editable via
> common tools in a way that makes sense to people not used to (or comfortable
> with) the object database, and to give people a plausible way to put a Zope
> site under source control.
> Are you thinking that we would build client-side tools to recognize an XML
> representation of a subpart of a site?

Client-side tools, no.  I'm thinking that exporting to XML would allow
existing tools to recognize and manipulate a subpart of a site.

I'm basically agreeing with you - "common tools" for manipulating text
sounds like parsers to me.

I'm not sure why XML is considered less readable than an unknown
format for Zope object serialization; I guess I haven't seen what's
being considered.  But it seems to me that for humans, XML might lose
by a little, but for any type of mediated or batch processing, XML
wins by a lot.  Parsers are standard enough that their APIs are easy
to learn if you've played with them before.

Random human-editable text formats sounds like StructuredText; when I
think of StructuredText I think "simple DOM serialization".

Is there a particular set of tools or editing paradigms that we have
in mind when we say that a non-XML representation is suited for client
side tools?

This is the way that Manila seems to be doing it:

Karl Anderson                          [EMAIL PROTECTED]

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to