"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 - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to