- From: <noah_mendelsohn@us.ibm.com>
- Date: Tue, 18 Oct 2005 22:16:21 -0400
- To: www-tag@w3.org
- Cc: kekelly@us.ibm.com
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
drafts:
* 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
[9]
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
requirements:
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
capabilities
--------------------------------------------------------------------------------
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.
Summary
-------
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
[1] http://www.w3.org/2001/tag/2005/09/21-tagmem-minutes.html#action05
[2] http://www.w3.org/2001/tag/2005/09/21-tagmem-minutes.html#action04
[3] http://lists.w3.org/Archives/Member/tag/2005Oct/0016.html
[4] http://www.w3.org/TR/2005/WD-WICD-20050915/
[5] http://www.w3.org/TR/2005/WD-WICD-20050915/#wicd-core
[6] http://www.w3.org/TR/2005/WD-WICD-20050915/#wicd-mobile-profile
[7] http://www.w3.org/TR/2005/WD-WICD-20050915/#wicd-desktop-profile
[8]
http://www.w3.org/2004/CDF/Group/specs/CDR/wp1/wicd-full.xml#doc-spec-xhtml-mp
[9] http://www.w3.org/TR/2005/WD-CDRReqs-20050809/
[10] http://www.macromedia.com/platform/
[11]
http://msdn.microsoft.com/windowsvista/default.aspx?pull=/library/en-us/dnlong/html/wpfandwbas.asp
[12]
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/stg/stg/structured_storage_start_page.asp
[13]
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/d17dc0dd-3115-4830-8c6b-694a8d1accaa.asp
[14] http://sc.openoffice.org/compdocfileformat.pdf
[15] http://en.wikipedia.org/wiki/OpenDoc
[16] http://www.w3.org/TR/2000/NOTE-SOAP-attachments-20001211
[17] http://www.w3.org/TR/xop10/
[18] http://www.w3.org/TR/soap12-mtom/
--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
Received on Wednesday, 19 October 2005 02:16:37 UTC