Use Case

Speaking as a consumer of XML and producer of HTML, I'd like to put 
forth a use case for the group to consider.

Our situation is that on the server side we deal entirely in well-formed 
XML so we can use the rich toolset that makes available, and because, 
well that's what our clients give us.  On the other hand, our consumers 
are primarily browser users, so we need to produce whatever browsers 
will handle in a reasonable way.  One area of persistent pain is 
providing CMS features that enable interactive content editing. This use 
case was already mentioned; I can provide some detail from an 
implementer's perspective.

We would like to be able to provide our users lightweight WYSIWYG 
in-browser editing tools that operate on XML, using vocabularies that we 
control. We have a few choices currently, none of which is ideal:

    A) render using XSLT in the browser; this is painful due to limited 
browser support for XSLT
    B) render in the browser using CSS only: this provides only limited 
presentation capabilities
    C) render using a server round-trip; this cripples the immediacy of 
the user experience
    D) Use a heavyweight tool (like Xopus) that essentially embeds an 
entirely separate client-side application in the browser.  This might be 
the best option, but we've been reluctant to invest the 
not-insignificant license fees and integration effort here.
    E) Something else we haven't found yet - suggestions welcome!

In practice, all the existing lightweight javascript-based editing tools 
we've evaluated are built for editing (X)HTML, not arbitrary XML 
vocabularies. As a consequence that's what we generally provide our 
users (using CKEditor), and we encourage them to edit XML using offline 
tools which we import server-side.  I should mention that it is possible 
(using CKEditor) to provide a data transformation plugin that converts 
to/from XHTML, but the effort to produce this has so far been a hurdle 
we haven't jumped over since it requires a custom parser/serializer to 
be developed in javascript (which would have to be customized for each 
XML vocabulary), and the benefit for us of doing this hasn't thus far 
outweighed the cost.

We would really like to provide in-browser XML-based editing, because 
control over the vocabulary lets us limit user error, it enables 
server-side processing to render alternate delivery formats, and it 
allows us to use the same processing and rendering pipelines for 
user-edited content that we use for our primary content (which we 
receive as XML).  Ideally we'd like to use the same XSLT for rendering 
in the editor that we do for rendering in our applications.

I'm not conversant enough with HTML5 to understand how it might alter 
this equation, but my perception is that it wouldn't, at least as it 
stands today.

-Mike Sokolov
sokolov@ifactory.com

Received on Wednesday, 22 December 2010 09:51:03 UTC