W3C home > Mailing lists > Public > public-xml-processing-model-comments@w3.org > April 2006

XProc and XML editing in Xopus

From: Laurens van den Oever <laurens@q42.nl>
Date: Wed, 12 Apr 2006 10:55:16 +0200
Message-ID: <646876D1454BE6468B01FDAEB1FC07811B4663@DS01.q42.local>
To: <public-xml-processing-model-comments@w3.org>
Cc: "Sjoerd Visscher" <sjoerd@q42.nl>

Dear W3C XML Processing Model comments list readers,

I've just read the XProc working draft (from April 10th 2006).
Congratulations to the working group for getting this off the ground. 

I was wondering how Q42 would be able use the standard in our XML editor
Xopus [1]. Xopus supports a set of views. Each view is a linear pipeline
of arbitrary depth with XSLT and XInclude resolve steps. Xopus validates
the input document using XML Schema. An example of our current pipeline
format is:

<pipeline xml="xml/doc.xml" xsd="xsd/schema.xsd">
  <view id="WYSIWYG View" default="true">
    <transform xsl="xsl/prepareIncludes.xsl"/>
    <resolveXIncludes/>
    <transform xsl="xsl/presentation.xsl"/>
  </view>
  <view id="Tree View">
    <treeTransform/>
  </view>
</pipeline>

When a document is loaded, Xopus will give each node an id. Also each
XSL stylesheet is modified so that it will generate a unique id for each
possible permutation of that node and that XSL. That information is used
to track the nodes through the pipeline. In the pipeline output (HTML)
we know exactly where each (partial) node came from, so we can convert
modifications in the pipeline output to modifications in the XML. We
only allow modifications that will not bring the document in an invalid
state. Once the XML is modified, the pipeline is executed for the new
content and the output is updated. When the user has finished editing
and saves the document, the changed XML source document is saved.

This workflow partially maps to XProc, for instance we could support a
branched pipeline with multiple input documents. But some Xopus
requirements may be hard to fit in the model.

Xopus can only validate what it loads since we can't predict whether an
action is possible when XSL output is validated. How could XProc handle
pipelines in restricted environments like this? We could raise an error
when an intermediate result becomes invalid, but that is not how Xopus
works, we prevent errors. Will there be an XProc subset "XProc editing"
that only allows input validation? Or could validation be optional for
instance?

Another issue is saving. XProc now saves the pipeline (intermediate)
output, whereas in Xopus that is where you edit, but what you load is
what you save. Our clients often want to save to a different location,
but they want to save the edited input document, not the pipeline
output. Do you see a solution for that?

And can/will XProc support multiple views?

Best regards,

Laurens van den Oever
Q42

1) http://www.xopus.com
Received on Wednesday, 12 April 2006 09:04:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:42 GMT