Web Applications/Compound Document Workshop Position Paper

Stephen Zilles, independent consultant

April 30, 2004

1 Introduction

There are a number of problems associated with "compound documents". The one which most interest me is providing a way to present, in a formatted form, the content of a compound document to a user using some marking technology (whether on screen or via some print mechanism). Note in my view, a "compound document" is one that contains content from two or more different namespaces.

One of the key issues in implementing such an environment that is hospitable to compound documents is being able to transmit styling information across namespace boundaries. This is a non-trivial problem, because the processors for the various components of a compound document/web application UI may not have anticipated the processors of the other components in that document.

To see some of the problems to be solved, let's consider some scenarios for typical use cases:

1. an XML "stockquote" namespace embedded in an XHTML namespace
2. an XHTML namespace embedded in an SVG namespace embedded in an XHTML namespace,

Scenario 1

Scenario 1 illustrates the inclusion of XML content, in this case stock quote data, within an XHTML document. This is a case where there are no presentation semantics associated with the XML content. An example for this scenario is:

<XHMTL>

   ....  

   <sq:quote xmlns:sq="http://www.example.com/stockquotes">
      <sq:company>MyCo</sq:company>
      <sq:price>10.52</sq:price>
   </sq:;quote>
   ....

</XTHML> 
  

Scenario 2

Scenario 2 illustrates the inclusion of a namespace that does have presentation semantics. In addition, it shows a case where the host namespace is itself embedded within another embedded namespace. In this case, the desired effect is that property values specified in the initial instance of the host namespace are available for inheritance in the embedded instance of the host namespace. An example of this scenario is:

<XHMTL>

   ....  

   <s:SVG xmlns:s="http://>

      ....  

      <foreignObject width="100px" height="50px">

         <XHTML>

            ....

         </XHTML>

      </foreignObject>

      ....
   </SVG>
   ....

</XTHML>   

where there is XHTML embedded inside SVG embedded inside XTHML.

Further, it is possible that the (embedded) processor for SVG may be distinct from the (host) XHTML processor.

The question of interest to me is, how is styling information propagated from processor to processor and made available across documents of this type.

It is expected that properties values specified in the outer XTHML would be available to the inner XHTML even though these properties are not necessarily properties used by SVG.

Styling Processors

To handle these scenarios, we need to assume that there is a styling processor (or processors) that both style the XML tree and format the styled tree for presentation on some medium; for example for presentation in a browser window.

There may only be a single ("monolithic") styling processor, such as a Web Browser, that knows about all the embedded namespaces or there may be several ("componentized) processors, one for the initial namespace of the document and one or more for namespaces of content embedded within the document (think plug-ins). In either case, given a node in the document, we say that the namespace of that node is the embedded namespace and the namespace of the nearest ancestor with a different namespace (or the namespace of the root node if there is no such ancestor) is the host namespace. Correspondingly, we will refer to the host styling processor or just host processor and the embedded styling processor or embedded processor.

It is assumed that a styling processor knows about a fixed set of namespaces that have builtin presentation semantics. New XML namespace can be and will be invented after the creation of any given styling processor.

Namespaces with Presentation Semantics

There are two kinds of XML namespaces, those that have builtin presentation semantics and those that do not.

An XML namespace has no presentation semantics if (and only if) a styling processor (e.g., a browser or a formatter) that has never seen that XML namespace before can correctly present instances of the XML namespace using only its knowledge of XML and a styling mechanism (such as CSS or XSL). If the correct presentation of the XML namespace requires prior knowledge of the namespace (e.g., XHTML or SVG) then that namespace has presentation semantics.

XHTML, SVG and MathML all have some level of builtin presentation semantics, but they also allow styling to be done with a styling processor, such as a CSS or XSL processor. XML namespaces without builtin presentation semantics, such as an XML representation of a database record, require a styling processor to be presented.

Style Processing

The basic idea is there is there are at least two steps to styling:

1. a "cascade" which distributes properties onto elements (could be CSS or XSLT)
2. inheritance which propagates the specified values down the document tree.

The above two steps characterize "style processing" as it relates to compound documents. Typicaly, the "cascade" is relatively independent of the namespace boundaries within a compound document. It is property inheritance that is more of a problem for implementers of processors (plug-ins) for a given embedable namespace. Inheritance is more difficult because it deals with the "computed value" of a propety rather than just the text used to specify that value.

We might consider three proposals for how an embedded processor gets property information:

1. There is a global property manager, which each (separate) processor tells about property values and that can be asked (by another processor) for those values.
2. There is a protocol (or API) that works between an embedded processor and its parent processor that allows requests for information about properties.
3. There is no way for a processor to inquire about properties (and, therefore, a processor that does not understand a property needs to use a solution like setting its value to "initial").

Of these proposals, the best one seems to be 2., a two node protocol between a processor for an embedded namespace that the processor of the namespace in which it is embedded. The second of these processors is the parent of the processor for the embedded namespace. (NOTE: It is not necessary that these two processors be different. A single processor may handle the semantics of both namespaces.)

This protocol might have an API for properties that has:

1. Given a property, an API to ask for a value for that property
2. an API to ask whether that property is inherited.
3. an API that allows the embedded processor to tell its parent what properties the embedded processor may be interested in.

The latter API allows the parent processor to be more efficient in storing values of properties it may be asked about versus ones that are of no interest to the embedded processor. Note, however, that a second, lower level, embedded processor may ask for properties the first embedded processor has no interest in (until asked about them by the second embedded processor).

Some of the interesting questions the must be resolved are:

• What is a processor for an embedded namespace to do with properties about which that processor has never heard, but which may be of interest to a processor for namespace embedded one level lower?

• How is information about the "initial" value of an unknown property to be conveyed to an embedded processor that has never heard of that property before?

Finale

I attempt no answer to the questions I raised nor any argument that only one form of value passing between separate, embedded processors make sense. Answers to these issue are necessary, however, to make progress on implementations of compound document or web application in which no single processor understands all of the component technologies used in the compound document.