Mailing List Archive

Michael R. Bernstein wrote:
[snip]
> I'd like to build a writing environment.
>
> I want to be able to use an (initially) web-based authoring environment
> that allows me to create book-length documents of arbitrary depth and
> complexity. I'd like the storage to use the DocBook XML DTD, and I'd
> like it to be able to produce PDF and HTML renderings (probably cached,
> rather than on-the fly).
>
> When editing the document, i'd like to be able to specify (by clicking)
> the scope of the element that I am editing (ie. a whole section, or a
> single paragraph).

While I'm not aiming initially at supporting a complicated DT like
DocBook, this is also a very important use case of mine.

I believe there are some advantages in layering this over XML and DOM
directly, instead of going the alternate route of creating a bunch of
custom Zope objects. DOM is perfectly capable of tree management already
and has a fairly straightforward documented API. You can generally
combine the best of both worlds by layering objects on top (dynamically).
Plus you always have a clear representation as XML, which makes import
and export more easy. It is also always possible to directly edit the
XML. And then you can leverage the whole set of XML standards (once
they're integrated with Zope, but XPath is already very interesting).

> Ultimately, once the web-based interface is usable, i'd like to create a
> dedicated client app for editing the document in outline (kind of like
> Radio Userland)

Not a nearby usecase of mine, though it may become necessary eventually.

> I'd like other users of the browser of desktop editor to add arbitrary
> markup and comments to my documents, that can be shown or hidden while I
> am doing my own editing, without those elements being discarded.

I think you can do this by working with XPointers of some kind. The
problem of course is that XPointers are unstable to document edits,
unless you manage to uniquely identify an element, for instance by
ID.

> I don't know how to resolve simultaneous edits to different parts of the
> document, much less how to resolve conflicting edits to the same
> element. diff is meant to be used on a serialized text format, not an
> object tree.

I don't know either. Simultaneous edits to different parts of the tree
were more or less possible with XMLDocument as they were seperate
persistent objects. With ParsedXML this seems harder; right now
everything would be a conflict like an edit to the same element. Resolving
that seems difficult.

> I don't know if this set of use-cases helps inform this debate, but
> that's what I'm (eventually) shooting for.

I think it is helpful, but that's because it's very similar to my own
use case. :)

Regards,

Martijn