[
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
http://xmlbuddy.com/
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
|
