Chris McDonough <chrism@digicool.com> 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: http://www.thetwowayweb.com/theXmlFiles -- Karl Anderson karl@digicool.com