"Chris McDonough" <[EMAIL PROTECTED]> writes:
> > > Are you thinking that we would build client-side tools to recognize an
> > > 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 [EMAIL PROTECTED]
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -