R
Richard Light
Hi,
I am looking to develop a change-logging framework for XML documents,
and am considering adopting XUpdate as a syntax for both making changes
happen and recording what changes have been made to a document.
However, not much seems to have happened to move XUpdate forward in
recent years: is there a reason for that which I should know about? Is
there a better-supported (non-proprietary) format? Also the XML
B site
appears to have lost the will to live (or at least to add new content)
some time last year.
Anyway, I have written one XSLT stylesheet which compares two documents
("old" and "new"), and generates an XUpdate document ("diffs") which
expresses the differences between them. I am now writing a second XSLT
stylesheet which actually invokes "diff", so that it takes "old" as
input and generates "new" as output. (This relies on use of the Saxon
extension function "evaluate" to turn the XPath expressions in the
XUpdate document into actual XPaths in the XSLT context.)
While struggling with the usual minor problem that it doesn't yet work
(!), it occurred to me that there is potentially a deeper problem with
the design of XUpdate.
If you have multiple updates in a single XUpdate document, you can't
magically apply them all at once. As you apply each edit, you change
the document's structure. By changing its structure, you potentially
invalidate the XPaths in the select attributes of subsequent XUpdate
expressions.
Or is the select attribute for an XUpdate expression meant to take
account of the changes which have already been made to the document by
previous XUpdate commands?
Richard Light
I am looking to develop a change-logging framework for XML documents,
and am considering adopting XUpdate as a syntax for both making changes
happen and recording what changes have been made to a document.
However, not much seems to have happened to move XUpdate forward in
recent years: is there a reason for that which I should know about? Is
there a better-supported (non-proprietary) format? Also the XML
B siteappears to have lost the will to live (or at least to add new content)
some time last year.
Anyway, I have written one XSLT stylesheet which compares two documents
("old" and "new"), and generates an XUpdate document ("diffs") which
expresses the differences between them. I am now writing a second XSLT
stylesheet which actually invokes "diff", so that it takes "old" as
input and generates "new" as output. (This relies on use of the Saxon
extension function "evaluate" to turn the XPath expressions in the
XUpdate document into actual XPaths in the XSLT context.)
While struggling with the usual minor problem that it doesn't yet work
(!), it occurred to me that there is potentially a deeper problem with
the design of XUpdate.
If you have multiple updates in a single XUpdate document, you can't
magically apply them all at once. As you apply each edit, you change
the document's structure. By changing its structure, you potentially
invalidate the XPaths in the select attributes of subsequent XUpdate
expressions.
Or is the select attribute for an XUpdate expression meant to take
account of the changes which have already been made to the document by
previous XUpdate commands?
Richard Light