John L. Clark wrote: > >>What about this which is much simpler to implement: if multiple sibling >>nodes are selected, > > >> <copyDocument selection="true" to="__doc.xml"> > > >>creates __doc.xml containing all the selected nodes wrapped in a parent >>``envelope element'' (using a fixed, documented, qualified name >>belonging to the XXE clipboard namespace). > > >>It would not be difficult for the XSLT style sheet to detect this case. >>Suffice to examine the qualified name of the root element of the >>document it has to process. >> >>After transforming the selected nodes, the XSLT style sheet could build >>a result tree using the same envelope in order to allow pasting the >>result back in XXE. > > > This would be another neat way to accomplish this end, and I thought of > suggesting this instead of my initial suggestion. It seems to me that > both approaches have interesting characteristics, which we can discuss > in a bit more detail if you would like. I would agree that the method > you suggest would be perfectly functional in this regard.
OK, you'll have this enhancement in next release. > >>PS: If you use macro-commands+process-commands to *interactively* >>transform parts of the document being edited, you should be annoyed by >>the slowness of <process>/<transform>. > > > I don't know if I would go so far as to say "annoyed". When it comes to > wanting to achieve transformations which would otherwise be very tedious > and error prone, I am willing to sacrifice a bit of speed (and really, > not too much - XXE pops up a window, does some processing, and then > substitutes the result - doesn't take but several seconds) to achieve > computational precision (and in the end, I'm almost certain that it is > faster than doing the same thing manually). For example, one of the > requirements that my users have is to be able to "wipe" all change > information in DocBook (delete remark elements or elements with > revisionflag="deleted" and merge those with revisionflag="added" or > revisionflag="modified"), and the slight amount of wait time on this is > well worth it. > > Of course, ideally this would be performed from the root (that is, > globally); thinking about this caused me to realize that being able to > process multiple siblings might be worthwhile. > > >>Currently <transform> does not cache precompiled XSLT style sheets. This >>is one of the reasons of this slowness. > > > It would be extremely exciting if it did caching like this, but I hadn't > even thought to ask for it because I knowingly and willingly pay the > cost to achieve a certain amount of functionality (described above). > > >>Don't you need an attribute which could be used to instruct <transform> >>to cache the XSLT style sheets you use in interactive commands? > > > I wouldn't mind one, but I will continue to happily use <transform> > without it. We'll try to implement XSLT style sheet caching for interactive commands in next release. Note that this means that you'll have to remember removing the cache attribute or setting it to false when you are in the process of writing your custom XSLT style sheet. > What a great discussion this has been, I appreciate it. My pleasure.
