"Chris McDonough" <chrism@digicool.com> writes:
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?
Parsers, transformers, etc.. I don't know of any end-user tools (are there any?), I'm talking about building blocks.
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.
Sure, I would use that, too, probably more than an XML representation, I'm referring to the ability to represent in other formats because of their usefulness and scalability. For example, if I were doing lots of random edits on a subtree of DTML files and Python scripts, I'd want them to look like a filesystem tree full of text files and I'd use emacs, grep, find, etc. on them. If I wanted to be able to use an automated tool to, say, update the spam and eggs fields of everyting in a subtree every friday, an XML parser and/or DOM tree and/or transform working on a single XML representation of the subtree checked out to the local filesystem seems like the easiest entry point. I'm probably straying from the proposal here. -- Karl Anderson karl@digicool.com