OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



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

[ Lists Home | Date Index | Thread Index ]

Thanks for this. Seems a bold conception of the problem and a 
non-trivial implementation. I shall have to try Xopus.

I assume, but you didn't say, that a CSS stylesheet applied to the 
output XML isn't a problem for Xopus, and, separately, that XHTML output 
is ok, too?

Bob Foster

Laurens van den Oever wrote:
 > 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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS