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