Zopinion : Wysiwig and "reversible style sheets"
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. XML and XSLT are viewed as the perfect data "tubing", that will finally allow easy integration of multiple data sources. XSLT is a powerful tree transformation language, that seems up to the task to enunciate any transforms between two equivalent XML-dressings of data. I believe a very desirable but completely overlooked feature of output styling, is REVERSIBILITY OF TRANSFORMS. I see two typical forms of uses for such a feature. (a) Wysiwig editing of styled output, with deconstruction and back-propagation of the updates to the store. (b) Networking data stores, again with backpropagation of distributed updates to the distinct mother store of each data item. I believe there may be long-term "second niche" for Zope with (b), and a more immediate opportunity with (a)... At a glance, (a) means opening a new model for web-based data acquisition, one that acknowledges that HTML forms weren't designed to provide superslick click-and-point, and, instead of trying to beat MS IE on its own ground, takes another road : have the app serve model documents that the user can modify with a wysiwig html editor (e.g. Amaya), and PUT back... whereupon the app (e.g. Zope) would parse the modifications and distribute them back where they belong... or return the same page, with red annotations for what doesn't parse. Couple motivational notes : (i) Of course, the design of an extensive "reversible style sheet" language is no small matter. But start in the small : think of the situation where one notices a mistaken digit in a figure in a web page. If the page is automatically generated and styled from a data store, wouldn't it be nice (and shouldn't it be possible !) to tell the system : "update the item from which that digit was obtained" - without further ado (except where security is concerned). (ii) There is a parallel to make, between the Closed/Open Source duality, and the Mono-/Bi-directional stylesheet issue, on the other hand. Bidirectional style-sheets are like open source, since they make it easier for the final consumers of data, to effect changes at the source of the data. (iii) Last week, someone posted the open source announcement of Xanadu/Unadax; from what I could gather at their site, their critique of current web technology parallels the above proposal. (iv) XLST doesn't beat DOM in the heart of many "procedurally minded" developpers; and indeed, the DOM is much more flexible. Bidirectionality is where a declarative language like XSLT could really excel. I write this thinking of the recent praise for XMLDocument; somebody spoke of the simplicity of using DTML for XML styling, as compared to XSL; this means that DTML is currently competing with XSL in zopeland, and there may exist a temptation for Zope development to continue on that lead. What I am saying, is that bidirectionality of transforms (which neither XSLT or DTML currently have) is a better ground to be critical of XSLT, since this is where XSLT's declarative style of programming should be stronger. Boris Borcic
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. Instead I've chosen a different route; I'm building a web based editing tool that can edit an XML Document (of only a single DTD for now; it's not a general XML editor). The XML document is transformed (with DTML) to HTML for display, but when the user makes a change in this document, the XML DOM tree is modified (instead of the layouted HTML). After that, the whole XML->HTML process happens again and you see the edited version of the document. This document isn't displayed in the full final layout; only enough HTML layout is shown to give an impression. I.e. there are paragraphs and titles and lists, but no sidebars and backgrounds and fonts. After the author is done with the XML Document (and the author doesn't know anything about the XML in the background; she's just working with a structured web-based text editor), a set of layout options can be chosen and the document can be published on the web. Some advantages of this kind of authoring environment: * web based -- no local clients necessary * _only_ DTD conforming XML is produced by authors * Authors don't need to know XML * layout independent from content; you can have a consistent look & feel of a site while employing different authors * You can use the XML in 5 years for something else The main disdvantage is of course that a web based interface is slow, clunky and limited. Basically the idea is much like Zope's structured text. The added advantage is that people don't need to learn structured text rules; they can't generate wrongly-structured documents at all. So, I think I'm trying to solve the some of the same problems without needing the reversibility bit. Regards, Martijn
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. 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. 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. 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). Reversible code is one of the beauties of logic programming... and zope acquisition smacks of the rational trees of Prolog III... 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. Boris Borcic
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
participants (2)
-
Boris Borcic -
Martijn Faassen