Joseph, Doing some research over this topic we came accross an effort called XUpdate: http://www.xmldb.org/xupdate/xupdate-wd.html - "The mission of the XUpdate Working Group is to provide open and flexible update facilities to modify data in XML documents. Doing so it is not important where the documents come from. It can be real documents or virtual documents retrieved from XML databases".
This new language being defined is supposed to describe document updates as opposed to document transformations. The key thing here is the assumption that the source document is the same as the result document. From a language point of view, I can see that having special language constructs to specify document updates may be more scalable. The reason being that instead of having to specify the whole transformation and then the specific things that need to be updated, only what needs to be changed is described. IMO I dont think that we need another language for document updates and it seems to me that XSLT could easily support this requirement reusing most of what it already supports in terms of transformation/selection/etc. I would see XSLT "transformations" describing transformations (as it greatly does today) into NEW documents/fragments of xml and XLST "updates" (maybe additional language elements, maybe a way to assign the source as also the result of a transformation) describing changes to a source document/fragment. If could rewrite the subject of my previous emails I would describe them as being "having support for document updates" instead of optimizing large XML document transformations. I do, however, see the direct performance benefits of having such update feature in cases were the user use cases call for. Thanks, Yuri > -----Original Message----- > From: Joseph Kesselman [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 01, 2003 3:03 PM > To: Yuri de Wit > Cc: '[EMAIL PROTECTED]' > Subject: RE: Extension Element to Optimize Large XML transformations > > > > > > > We should keep this discussion on the mailing list, so others can > participate. > > > A custom DTM wrapping my own data models seems > straightforward looking at > > the implementations you pointed out. However, one thing > that is not very > > clear to me is how to pass an intance of that custom DTM > impl to Xalan. > > The simplest solution might be to write an extension that > returns a custom > DTM implementation. The SQL extensions are an example of that > approach. > > If you prefer to change Xalan's basic behavior... The factory > for DTMs is > DTMManager. The factory itself is loaded via the > DTMManager.newInstance() > method, which reads the class name from the system property > "org.apache.xml.dtm.DTMManager". You should be able to create a new > subclass of Source, subclass DTMManagerDefault to recognize > that kind of > Source and instantiate your new variant of DTM, and change the system > property to load your new DTMManager rather than the standard > DTMManagerDefault. Then simply pass your new Source object to > the Xalan > APIs, and we should Do The Right Thing.(It's been a long time > since I tried > this, and there may be some obscure details to watch out for, > but it ought > to work.) > > > One bit of advance warning: It is possible that we may > replace the DTM APIs > at some point with another abstract data model. (DTM's use of > integers as > Node Handles has some significant drawbacks, as the DOM2DTM2 code > demonstrates.) If we do so, your DTM adapter would have to be > rewritten, > just as our other DTMs/adapters would have to be rewritten. > This is one of > the issues we're still trying to nail down. I don't think I'd > advise you to > wait for us, but you should be aware that your first draft > may have to be > rewritten if the architecture changes. >
