[Zope-dev] Zopinion : Wysiwyg and "reversible style sheets"

Martijn Faassen m.faassen@vet.uu.nl
Tue, 31 Aug 1999 10:56:11 +0200


Boris Borcic wrote:
> 
> Martijn Faassen wrote:
> >
> > Boris Borcic wrote:
> > >
> > > I've like many been keeping an eye on XML and XSLT. It
> > > seems to me, that the high interest in these technologies
> > > suffers from an astonishing blind spot : reversibility.
> > [big snip]
> >
> > I'm not sure if I get you here. I think reversing wysiwyg documents back
> > into semantic content (XML) is very very hard, if not plain impossible.
> > A different layout, especially with the current HTML table hacks, can
> > really transform the way a document looks, and you'd need heuristics to
> > make this work well at all; and heuristics don't always work.
> 
> Well, my idea would be to have appropriate html comments embedded into
> the generated html, that would be preserved by the editor, and would
> make the parsing of the modified document more deterministic. I don't
> think a downsized version of such a facility would be as hard as you
> say; but it certainly requires the expression logic (e.g. DTML or XSL)
> to be designed from the start with such a facility in mind.

Hm, I've already done something a bit like this. In an XMLDocument, each
node in the DOM tree gets a unique id (in that document), and a unique
URL based on those ids (doc/e1/e5, for instance). When translating to
HTML, I add in hyperlinks that point to those URLs, and call methods on
them (doc/e1/e5/edit, for instance).

This way the displayed HTML becomes a set of 'widgets' that have events
that do things with the DOM. Incidentally I came across this web page (I
think in the docsection of http://coldstore.masslinux.com) yesterday
that used this widgets terminology, so thanks to them. Coldstore itself
is interesting anyway; if I understand it right it's a low level object
store -- parts of the API are inspired by Python's and there is
apparently a Python binding planned, which could be interesting for
Zope.

> As a first step, one could concieve that the "rendering primitives",
> translating an object to text, could tag their output with a machine-
> -readable comment, indicating both the source object and the formatting
> function that is "adjoint" (= the best reverse) to the one used to
> render the object.

In my scheme there's no reversibility, but the output *can* reach back
into the structure of the document directly.
 
> More thinking is required, when the matter comes to modifying aggregates,
> e.g. adding or removing a row to a set produced by a looping construct;
> but there again, the looping constructs could embed "reversibility
> information" into html comments.

As long as each node has an unique ID that's somehow placed into the
rendered document, you can get a long way, I think.
 
> In any case, what I have in mind are *simple* layouts, intended for
> such an usage. The user would be allowed to do wysiwyg editing, only
> to the extend that the document's structure makes the intended change
> clear. Again, the primitive example, is that of being able to change
> the source of a mistaken digit by updating that digit in the output:
> and the application should certainly be able to track such a digit
> back to its source (I mean, I don't think this would require a true
> miracle).

Well, I'm working on something quite like that. :)
 
> Reversible code is one of the beauties of logic programming... and
> zope acquisition smacks of the rational trees of Prolog III...

I have some Prolog knowledge (old and far away), but don't know what
rational trees are.

> while
> the request-by-request logic inherited from the HTTP protocol reminds
> of prolog queries - especially as regards failures. I am wondering
> if pushing this (admittedly vague) convergence can lead to further
> treasures.

I can see a request as a Prolog query (though it's easier to see it as a
method call, of course :). How are the failures like a failed prolog
query, though?

Anyway, these vague similarities can indeed lead to new ideas.

Regards,

Martijn