On behalf of Gordon Jones I forward this message to the Developer list: Begin forwarded message:
Date: Thu, 17 Jan 2002 10:46:57 +0000 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: re: XUpdate and XSL Lars, I am still having difficulty posting to the XUpdate developer list, can you post this please: Given the recent notes about Xupdate and XSL, I thought you might be interested in this exchange between myself and Michael Kay (of Saxon fame). In Mike's response he says that it is unlikely that an XSL engine could directly propogate deltas of a source tree onto deltas of the result tree. Original note: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mike, You will recall I wrote to you a few weeks back about in situ update of xml DOM trees using XUpdate. Well our experiments have progressed a lot further, and also I have read your XSLT book. I feel I am in a better educated position to express our requirements. In your book, on page 38 in the section justifying XSLT's functional programming style you almost exactly express our requirements: "Equally, if a small change were made to the XML document, it would be nice to be able to determine the change needed to the screen display, without recalculating the whole thing from scratch" To be more precise what we want is for a transformation engine to incrementally apply updates to a result DOM tree as the source tree is changed. In addition we want these updates to be made available independently of actually applying them to the result tree, so that they can be applied remotely to duplicates of the result tree. Why do we want this. Well there are at least four reasons: Replication Caching Publish/Subscribe Server push technology in a browser environment In all these distributed situations, a remote system has a "duplicate" of some source material which needs to be kept in step with changes to the source. In our distributed application framework, we have proprietory techniques to deliver and apply just the changes to the duplicate. Sometimes the duplicate is not quite the original material, but some "derived" data. As we move towards integration with other applications, and more use of thin clients, we would like to move to more open standards, but retain the concepts that we have developed. In particular, XSLT looks ideal as the tool to describe our derivations, and XUpdate (http://www.xmldb.org/xupdate), or something like, it looks ideal for describing the incremental changes to both the source and result trees. The integration of these two technologies would meet our requirements beautifully. I do not believe that our requirments are especially unique? Regards Gordon Jones <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Mike's response: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > "Equally, if a small change were made to the XML document, it > would be nice to > be able to determine the change needed to the screen display, without > recalculating the whole thing from scratch" I have to confess this is a statement of a goal, and I really don't know whether it is realistically achievable. Some XSLT development tools such as Stylus have put some mechanisms in that link elements in the result tree back to the rules in the stylesheet that caused them to be output, but I think they've done this in a fairly trivial way. Linking it back to the elements in the source tree that provided the input to that rule is much harder, at least in the general case, where you need to take into account parameter passing and so on. > > To be more precise what we want is for a transformation > engine to incrementally > apply updates to a result DOM tree as the source tree is > changed. In addition we > want these updates to be made available independently of > actually applying them > to the result tree, so that they can be applied remotely to > duplicates of the result tree. > One thing to start with might be a "diff" between two trees that outputs an XUpdate script which will modify the first tree to be a copy of the second. Another might be a DOM wrapper layer which intercepts all updates to a DOM and keeps a record of them or fires of trigger events, to construct an XUpdate script to reproduce the changes elsewhere. It's less clear to me where XSLT fits in. You could do some kind of restricted XSLT in which it's clearer which rules need to be triggered when the source document changes, but there's still a need to keep linkage to the relevant part of the result tree. I'm not sure how far you can go without maintaining some complicated three-way linkage between nodes in the source tree, nodes in the result, and rules in the stylesheet, which could get awfully complex (and be harder to analyse than re-evaluating the whole thing from scratch.) For example, if the result document contains a total, then it has to be updated if any of the source values changes. Or you could do something that's "XSLT-like" but is actually a trigger language: "when this node changes, do this". <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Regards Gordon Jones -- ______________________________________________________________________ Lars Martin mailto:[EMAIL PROTECTED] SMB GmbH http://www.smb-tec.com ---------------------------------------------------------------------- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ ----------------------------------------------------------------------
