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.
Which ones?
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.
XML doesn't play with diff very well... additionally, XML isn't as easy to work with as what I think it should look like. For example, I'd rather serialize a PythonScript into: def foo(self): print "hi!" than... <?xml version="1.0"?> <pythonscript> <function> <functiondef name="foo"> <arg>self</arg> </functiondef> <functionbody> print "hi!" </functionbody> </function> </pythonscript> The former is easier to understand.
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?
Yes.. anything that works well with diff and CVS and is recognizable by a human. PythonScripts should be serialized to something that looks like a regular Python script. Images should look like images, etc. The directory tree generated should look as much as possible like a normal filesystem. I can see a middle ground that's more parser-friendly, but it's sorta a different goal AFAICT. An XML rep might let you use something like XSLT to do some transformation across all the representations of the objects that a more human-friendly representation wouldn't, but it would lose lots of other utility which I think is more aligned with the goals of the proposal I put up... that's not to say that a middle-ground XML representation somewhere between "ppml" (XML export format) and human-friendly isn't something that's desirable for lots of folks, it's just not what the proposal was about.