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