[xml-dev] Xopus Explained (was: Re: [xml-dev] xml editors)

["Laurens van den Oever" <laurens@q42.nl>]

Bob Foster wrote:
> Robert Koberg wrote:
>> Sjoerd Visscher wrote:
>>> You are exactly describing what Xopus does. (http://xopus.com)
>>> <snip/>
>>
>> How is this possible? What if your transformation is lossy or adds
>> things?-- How do you know what to roundtrip?
>>
>> Can you have multiple content pieces on a page? How do you know where
>> content pieces are as opposed to page structure?
>
> I can't answer for Xopus (and I'd like to hear their answer)
> <snip/>

Though Bob already did a good job giving our answer, I can give a more
in-depth explanation why Xopus can do what it does.

First of all Xopus doesn't roundtrip XML. I agree with Robert, this
isn't possible. Though some editors (eWebEditPro+XML for instance) are
featuring this method.

Xopus takes the original XSL and transforms it to an XSL' that keeps
track of each source node. This XSL' is functionally equivalent to the
original XSL except that each output node can be traced back to an input
node. Xopus can use this method to keep track of nodes through any
number of consecutive XSLs. It supports multiple input documents using
XInclude. And Xopus can follow elements, attributes, text nodes,
processing-instructions and comments and all conversions between these
node types.

So you can have an attribute in your source document, convert that to a
processing-instruction using the first XSL and finally render it in the
output as a text node and Xopus is still able to trace it back to the
original attribute. 

Node values that are modified using string functions will become
uneditable. The modified string result will still be traced back to the
original node though.

Like Bob mentioned, is it possible to confuse the tracing algorithm, but
worst case you just can't select certain nodes to modify them. We have
yet to encounter an XSL where that problem can't be fixed with some
simple modifications (which don't affect the functionality of the XSL).
And I haven't seen any real world XSL confusing the Xopus tracing
algorithm.

If the cursor is in a <H1/> element in the output that can be traced to
a <title/> element in the input and the XML Schema allows deletion of
<title/> in that context, the delete button will be active and the user
will be able to delete the <title/> element.

After the user has modified the XML, the complete pipeline is executed
to update the WYSIWYG view. This allows you to use complex logic in the
XSL like sorting and conditionals.

There are a few limitations to this method, most of them not caused by
the technique, but by our XSL to XSL' transformation. Xopus doesn't
support apply-imports, disable-output-escaping (the XSL output must be
XML) and whitespace is always preserved. And if you use select on
value-of or copy-of, you must either refer to a node set or use
string(), number() or boolean() to type your expression. We may be able
to remove these limitations is future versions of Xopus.

Robert, I hope this anwers your questions. I also like to add that Xopus
is written completely in Javascript.

For more information you can visit our website ( http://www.xopus.com )
or attend my presentation at XML Europe 2004 ( http://www.xmleurope.com
) next Wednesday in Amsterdam.

Best regards,

Laurens van den Oever
Q42