Hello Joseph,
Thank you for your fast response.
Am Donnerstag, 28. April 2005 um 15:52:19 meintest Du:
JK> You may want to look at the articles I published on IBM's DeveloperWorks
JK> site, which demonstrate how to use XSLT to annotate an XSLT stylesheet so
JK> its output will include that sort of information. This should be a much
JK> easier approach to prototype than modifying the transformation engine would
JK> be, and ought to be portable across transformation engines.
Great article. I just had a small look at it, and will read it thoroughly later.
I just wasn't sure if the information i would get out of the transformation process
would be enough to link back to my original document in all cases.
JK> (For what it's
JK> worth, I've figured out how to generate a portable XPath to replace the
JK> "pseudo-XPath" I used in that article: by matching the local name and
JK> namespace as predicates. It's not a very human-readable solution, but it
JK> may be entirely reasonable for tooling purposes.)
Could you send me more information about this? It seems, like I will need it.
JK> The problem with WYSIWYG in XSLT is that in a significant number of cases
JK> the output at a given point depends on decisions made elsewhere --
JK> switching into and out of modes, setting variables, etc. Properly tracking
JK> all those dependencies, as you must in order to do selective
JK> re-transformation, requires spreadsheet-like logic at the least and may
JK> rise to the level of complexity of an optimizing compiler. I'm sure it can
JK> be done, but it's a larger problem than most folks assume.
I am aware about that. I know, that, to achive this, I have to remember _all_
xpath expressions including their contexts in my result, and then, if i change
the xml, i could use those back references to update the result tree. I hope
to be able, to reevaluate all of them fast enough :).
JK> Another issue: If you want to actually type into the rendered copy, you get
JK> into situations where changing a value may cause the item you're trying to
JK> edit to completely vanish from the screen, leading to the question of how
JK> to get access to it to continue editing.
This is completly true. Other issues are e.g. what if the stylesheet uses the
random()-extension, or some other nondeterministic extension functions.
More problems: What, if the stylesheet replaces normal 1:1-Procession of a
nodes content to output with uppercasing the same text after you entered a few
values? What, if the text now gets rendered by another rule, even if it looks
the same? (Might be possible with multiple cursors in the result tree)
JK> This tends to make traditional
JK> WYSIWYG editing inappropriate for XSLT unless you have specifically coded
JK> your stylesheets so that situation doesn't arise. Generally, for something
JK> with XSLT's power, a "text compilation" environment with rendering into a
JK> separate window is a better bet than WYSIWYG in its usual sense.
I know that i need this, too. Most xml that gets rendered by stylesheets, contains
information not rendered, e.g. linktargets (if you want to define links in xml),
or just some metainformation like the author of the document beeing styled.
>> Q1: Is it possible to start transforming just for a small range
JK> See above. The general answer is "no", but this depends on the interaction
JK> between stylesheet and source document. If you want to do this, you're
JK> really looking at building a different transformation engine to support it.
JK> That implies answers to Q2 and Q3.
Okey, my question was misleading. I just thought about taking one node, and
applying a template to it. Just this part :). Of course there would be many
templates (or parts of templates) to be reevaluated for some changes. Detecting
them would result in the new engine, I think.
>> Q4: Can I reuse compliled XPathExpressions, if the underlying DTM
JK> changes? (For
>> Speed)
JK> The only version of DTM which is currently able to
JK> tolerate being changed (and that only between invocations of our other
JK> APIs) is DOM2DTM2, and it was created precisely for that sort of
JK> application.
Okey, I will try it.
>> Q6: Do you think I am completly mad trying this? :)
JK> Well, it's an interesting research project. Doing it _well_ is a
JK> significant challenge. Whether you're mad depends on whether you think
JK> it's going to be easy and how much time you're willing to invest.
I hope to be able to find a solution that wouldn't cover exotic case and
works in most reasonable cases. I hope, that my evaluation shows, that
it doesn't need too much time (must be completed in 5 months).
Thank you and greetings,
Daniel
