> The base concept is to annotate every generated output with the location and > templates in the xslt-file, that were responsible for generating each output > fragment.
You may want to look at the articles I published on IBM's DeveloperWorks site, which demonstrate how to use XSLT to annotate an XSLT stylesheet so its output will include that sort of information. This should be a much easier approach to prototype than modifying the transformation engine would be, and ought to be portable across transformation engines. (For what it's worth, I've figured out how to generate a portable XPath to replace the "pseudo-XPath" I used in that article: by matching the local name and namespace as predicates. It's not a very human-readable solution, but it may be entirely reasonable for tooling purposes.) > Now when i add some text to the result document, i can find out the source > location in the xml document, change that, a by scanning the xpath querys in > the result document, i can find out which parts of the transformation i have to > redo. The problem with WYSIWYG in XSLT is that in a significant number of cases the output at a given point depends on decisions made elsewhere -- switching into and out of modes, setting variables, etc. Properly tracking all those dependencies, as you must in order to do selective re-transformation, requires spreadsheet-like logic at the least and may rise to the level of complexity of an optimizing compiler. I'm sure it can be done, but it's a larger problem than most folks assume. Another issue: If you want to actually type into the rendered copy, you get into situations where changing a value may cause the item you're trying to edit to completely vanish from the screen, leading to the question of how to get access to it to continue editing. This tends to make traditional WYSIWYG editing inappropriate for XSLT unless you have specifically coded your stylesheets so that situation doesn't arise. Generally, for something with XSLT's power, a "text compilation" environment with rendering into a separate window is a better bet than WYSIWYG in its usual sense. > Q1: Is it possible to start transforming just for a small range See above. The general answer is "no", but this depends on the interaction between stylesheet and source document. If you want to do this, you're really looking at building a different transformation engine to support it. That implies answers to Q2 and Q3. > Q4: Can I reuse compliled XPathExpressions, if the underlying DTM changes? (For > Speed) You should be able to. The only version of DTM which is currently able to tolerate being changed (and that only between invocations of our other APIs) is DOM2DTM2, and it was created precisely for that sort of application. However, it is experimental and I think is not curretly in use. > Q5: Dis someone do this before? There are commercial products in the xml-and-xsl-editing arena. > Q6: Do you think I am completly mad trying this? :) Well, it's an interesting research project. Doing it _well_ is a significant challenge. Whether you're mad depends on whether you think it's going to be easy and how much time you're willing to invest. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
