Translated Offset to Source Offset

[Lance Riedel]

I was wondering if anyone has seen/knows of a solution to the
following: given a document that has been translated through xsl, if
you have a character offset in the translated document, can you get
back to a specific location in the original xml document.

I know the answer is yes, because this is how WYSIWYG editors work.
Almost any editor can give you a graphical representation of the xml
(usually using xsl), and any cursor movements reflect back to your
position in the xml. (Think of a split screen view with the translated
rendered view and the original xml).

So with no editor available, and taken to its basic elements (you only
have the translated document, the original xml, and the xsl), can you
map offsets back and forth (i.e. just like the WYWIWIG editor would)?
This may be easier if the translated document is valid XML, and there
is a full XPath to to the offset.... but I'm trying to figure out all
possibilities.

Thanks if anyone has any pointers on this one.

 

[Richard Tobin]

I was wondering if anyone has seen/knows of a solution to the
following: given a document that has been translated through xsl, if
you have a character offset in the translated document, can you get
back to a specific location in the original xml document.
No.

I know the answer is yes,
Oops.

because this is how WYSIWYG editors work.

Presumably they are unusually chummy with their XSLT implementations.

An XSLT implementation could provide extra information to let you
do this - say giving the offset of the source to which the template
was applied to produce the result - but it's not portable, just
part of the implementation.

I suppose it would be possible to transform a stylesheet (using a
stylesheet, naturally) to make it annotate the output with, say,
processing instructions that would help.

And of course given a particular XSLT implementation, it would be
possible to "instrument" it to produce the necessary information.

-- Richard

 

[Patrick TJ McPhee]

% I know the answer is yes, because this is how WYSIWYG editors work.
% Almost any editor can give you a graphical representation of the xml
% (usually using xsl), and any cursor movements reflect back to your
% position in the xml. (Think of a split screen view with the translated
% rendered view and the original xml).

I wouldn't think that any WYSImolWYG editor that works on XML source
uses XSL in the process. The formatting is likely to be applied with
something more like CSS, so that the editor works directly on the
original tagged data, but the displayed output hides the tags.

% So with no editor available, and taken to its basic elements (you only
% have the translated document, the original xml, and the xsl), can you
% map offsets back and forth (i.e. just like the WYWIWIG editor would)?

In general, the content and structure of a transformed document is
different from the original, so there can be no mapping. One point
in the original might appear in more than one place in the target
(for instance, if the target is a report with summary information in
more than one format). Another point might not appear at all.

Even if you restrict your transformation to ensure a 1-1 correspondence,
keeping track of which bit in the source maps to which bit in the target
requires you to have state information, which XSLT doesn't allow. It
can be done using extensions, but you may be better off not using XSLT.

% This may be easier if the translated document is valid XML, and there
% is a full XPath to to the offset.... but I'm trying to figure out all
% possibilities.

It's not clear that XPath will be helpful in this, either. At least,
it would be less work for your extension to keep track of the node
in the result tree than for it to dynamically create an XPath
expression which returns that one node from the result tree.