Analysis of Compound Document Use Cases and Requirements

This note is in fulfillment of my action [1]:

> ACTION: NM to review CDF requirements and report back

Note that Tim has a similar action recorded at the same time [2]. 
According to Dan's recollection of the F2F, the intention is that Tim and 
I do separate reviews.  Note also that I recently sent member-only email 
[3] discussing some issues relating to CDF and TAG issue 
mediaTypeManagement-45.  The requirements documents that are the subject 
of this email are public working drafts, hence this note is being sent to 
the TAG public list.

I've included some background on CDF's work and an analysis of their 
proposed requirements.  If you don't want all the details, skip to the 
short summary at the end.  It briefly restates the important conclusions.

CDF Background

The Compound Document Framework group has published several working 

* Compound Document Framework 1.0 and WICD 1.0 Profiles [4].

The Compound Document Framework describes a general means of composing 
namespace-qualified XML vocabularies into a compound document.  It covers 
a number of specific issues relating to the processing of such documents, 
including "the propagation of events across namespaces, the combination of 
rendering and the user interaction model".

WICD, or Web Integration Compound Document, is a specific embodiment of 
CDF using XHTML, SVG, and CSS.  WICD itself is factored into a core 
Profile[5], which is common to all flavors of WICD, and two specific 
profiles: WICD Mobile [6] for handsets, and WICD Desktop [7] for devices 
with large screens and pointing devices.  Note that the WICD Core requires 
that the Root element be XHMTL [8]. 

* Compound Document by Reference Use Cases and Requirements Version 1.0 

The term "By Reference" refers to compound documents that are created 
using links, so the piece parts are found by reference, and are not in 
general packaged together.  The CDF group has also begun work on a similar 
set of requirements for Compound Documents "by inclusion", in which the 
several vocabularies are combined together in a single Infoset tree. 
Requirements for "by inclusion" are as yet unpublished, but a look at 
internal drafts suggests that not much has yet been done that would merit 
separate discussion;  so far most of the requirements are common to the 
two.  Accordingly, I think we can just look at [9], which has the 
advantage of being a public document.

Analysis of the Requirements

There are several angles from which one can consider the compound document 

I. CDF is a general facility for composing the piece parts of XML 
documents.  Arguably it should be long lived and applicable to a variety 
of specific XML formats as technology evolves.  So, we may ask whether the 
requirements listed are the right ones to ensure success for a broad range 
of uses and over a long time.

II. The short term CDF focus is clearly on WICD, which is a composition of 
specific W3C technologies including XHTML, SVG, CSS, and where appropriate 
MathML, etc.  We may ask whether the use cases and requirements are 
appropriate to the natural audience for such HTML-rooted documents.

III. The TAG has recently discussed Rich Applications.  Examples are 
embodied in commercial frameworks such as Macromedia (Adobe) Flash and 
Microsoft's Windows Presentation Foundation - WPF (Avalon) {11]. (If 
anyone from Microsoft has more appropriate WPF/Avalon links, please post 
them.)  These technologies focus on fluid, multimedia oriented user 
interfaces with extensive use of animations for text as well as for 
images, deep integration of video, etc.  Some support 3D as well.  To some 
degree these developments are a reflection of the increases in processing 
power and graphics capability that have become available since HTML and 
other Web technologies were first deployed.  One may ask whether the CDF 
Requirements are appropriate for bringing to the Web rich documents and 
applications that will be increasingly common in other systems.

The sections below represent an initial attempt to review the Requirements 
from each of those perspectives.  A fourth section has a few comments on 
specific requirements from the CDF working draft.

I. Review of Requirements for CDF as a general framework for composition

I'm concerned that the CDF WG is really only looking at one family of 
initial uses for what is to be a general compositional framework.  The 
requirements might be stronger if user interface and event composition 
were separately layered from the core hierarchical semantics common to all 
compound XML documents. 

As Tim Berners-Lee has often noted, self-describing documents are key to 
the architecture of the Web.  In my opinion, the CDF WG has the 
opportunity to specify clear semantics for a broad range of 
multi-namespace XML documents, not just those that involve user interface 
and interaction.  So, that's among the reasons I'm suggesting the layers 
be separated, and that attention also be given to the core. 

By contrast, the current requirements working draft focuses mainly on user 
interface event hierarchies, etc. that are clearly appropriate and useful 
for compositions involving XHTML and SVG, and may or may not prove to be 
the right ones for other uses of compound storage. 

For comparison, earlier non-W3C efforts to produce compound document 
formats, such as Microsoft's Docfile [12, 13, 14] and OpenDoc Bento [15] 
did have exactly the separation I'm suggesting.  The core structured 
storage specifications provided nested object storage with tagging for 
nested object types.  Semantics were associated with the object types. 
Compound user interface systems such as OLE-2 and OpenDoc were layered 
separately on these more general compound storage abstractions.  I think 
CDF might benefit from a similar separation.

I'm also a bit suspicious of the statement:

"Each phase [I.e. of development of applications of CDF ... NRM] results 
in a new version of the Compound Document Framework specification." 

I would have thought the whole reason for separating the framework would 
be to have it stable as successive uses of the framework come along. While 
minor revisions might prove necessary, I'm a bit nervous that we're mixing 
requirements for a general framework and for its initial application.

II. Review of requirements for WICD

I think the document does a pretty good job of dealing with these, as long 
as the goal is to support the sorts of documents and user interfaces 
associated with XHTML, SVG, CSS, etc.  A few specific comments:

* Printing appears not to be addressed, but would seem to be an important 
requirement for WICD.

* I wonder if there are unaddressed issues relating to composition of 
transforms.  For example, it is possible in some non-CDF systems to do the 
equivalent of nesting an HTML document in an SVG container, and applying 
transforms such as rotations to the nested document.  Is that a 
requirement for WICD, and if so is the requirement stated?  3.2.18 talks 
about "Real Estate Negotiation", but that sounds much more limited.

III. Review of requirements for CDF to support emerging application 

As we know, very flexible multimedia and animation capabilities are 
available in systems like Flash today, with scalable, transformable 3D 
interfaces planned in Microsoft WPF for later this year.  The CDF 
requirements don't clearly discuss the possible need to support such 
richer capabilities in future Web standards.  While the W3C is still 
discussing whether and how to invest in such richer application models, I 
would hope that at least the core compositional aspects of a CDF format 
would be suitable when the time comes.

On balance, given the timing of the efforts, I think the best we can do is 
to recommend that CDF attend as effectively as possible to the point made 
in I. above, that is to separate the basic semantics of dealing with a 
multi-namespace XML document from particulars of user interface, event 
handling, etc.  Beyond that, I recommend that the CDF group revisit its 
requirements and priorities should an applications model workgroup be 
chartered.  I don't think we can assume that everything being proposed 
today will be the right basis for that work (but I'm optimistic that much 
of it will be.)

Comments on Specific CDF Requirements

The above summarizes my main comments on the CDF requirements.  Here are a 
few other details that turned up.  Either the TAG can pass them on, or 
else I can send them later as personal comments.

* Section 1.3.8 References "SOAP Attachments" [sic].  There is no 
specification by that name, as far as I am aware.  There is a W3C Note 
called "SOAP with Attachments" [16].  It is quite widely implemented but 
not a Recommendation.  More recently the  XOP [17] and MTOM [18] 
Recommendations have been developed to address packaging of binary objects 
with XML, and integration of such objects with SOAP respectively. 
Suggestions:  correct the name to "SOAP with Attachments" and consider 
referencing XOP and MTOM.  Provide links to the pertinent specs.

* 3.1.20 talks about integration with Web Architecture.  I found it to be 
appropriate and effective.


The most important questions seem to me to be:

* Are the requirements for a generalized XML compound document 
sufficiently separated from those for WICD in particular?  Issues relating 
to event propagation, screen real estate negotiation, etc. apply to the 
latter but seemingly not the former.

* In particular, is there a  requirement to set out the basic semantics of 
a multi-namespace XML document?  As Tim Berners-Lee has often pointed out, 
this is an important aspect of creating self-describing documents on the 
Web.    Media type application/xml tells you to interpret the document as 
XML.  The CDF WG has the opportunity to state general or default rules for 
interpreting such documents recursively, starting with the root elements. 
In my opinion such rules should not involve UI or other client-side 
abstractions.  They should be about the hierarchical semantics of the 
document, and the corresponding delegation of responsibility for writing 
specifications to cover each embedded abstraction (e.g. the HTML spec 
effectively delegates to SVG when the latter is contained in the former.)

* Because the W3C has not yet decided whether and how to get into the 
business of building rich applications, we aren't yet in a position to do 
an organized job of ensuring that the requirements for CDF in particular 
are the right ones for those richer applications.  Getting the 
requirements synced up will be crucial when the time comes, but I'm not 
sure there's much we can do now except layer the CDF requirements in the 
manner suggested in the first point above.

I hope this analysis is useful as input to TAG discussions.  Thank you.



Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142

Received on Wednesday, 19 October 2005 02:16:37 UTC