Position Paper: Device Independence Workshop on Delivery Context

Larry Masinter, Adobe Systems Incorporated

Background

Adobe Systems Incorporated is a leading provider of products and services in support of network publishing: "Publish anything, anywhere, on any device."

Adobe has been a leader in defining industry standard for device-independent representations, as the developer of Postscript, PDF and as a leader in many other industry standards.

Adobe has significant experience in the area of Delivery Context. For example, Postscript Printer Description files include detailed information about printer capabilities and characteristics. To support accurate color reproduction, several technologies are involved in describing the delivery context for color.

In the area of content description, Adobe has developed and released an open source implementation of its eXtensible Metadata Platform (XMP), based on RDF, which may include content characterizations.

Terminology

It may be helpful to define terminology. Author, publisher, distributor and viewer are typically roles for people and organizations. Sender, intermediary and receiver are roles in the network architecture. The application is delivery of content from the sender to the receiver. Intermediaries act as agents that receive content (acting as a receiver) and subsequently send it toward its ultimate destination (acting as a sender), while performing some value-added service such as caching or content adaptation.

Delivery context includes information about the receiver's capabilities, characteristics and preferences, as seen by or communicated to the sender (and possibly modified by intermediaries), and content descriptions within or associated with the content about the content itself. Architecturally, this contextual information can be used in several ways, including:

Content adaptation
The sender determines the capabilities, characteristics or preferences (CCPs) of the receiver or and adapts the content for the context.
Content selection
An agent (sender, receiver or intermediary) chooses among available variants for transmission (based on matching receiver CCPs with content attributes).
Adaptive content
The content itself contains scripted or descriptive content alternatives.

Position Statement

When possible, it is far preferable to use a consistent device-independent content format as the primary carrier of content. Device independent representations have extraordinary advantages, both technically (e.g., better caching, reliability, ability to use digital signatures to verify authenticity) and operationally (minimizes necessary infrastructure to provide transformations, update versions of deployed software, maintenance of content adaptation, profile recognition, etc.) In situations where content adaptation is necessary, the following principles apply:
Late adaptation, if at all

If it is necessary to provide content adaptation, because of limitations of bandwidth or device computational power, the adaptation should happen as late in the process as possible. If necessary, device-independent formats should be enhanced to provide hints for adaptation.

Uniform vocabulary

We are not served well by specialized vocabularies devised for single applications. Ultimately, content authors will want broader contexts of delivery than whatever they're using now; makers of software for receivers will want to adapt or interpret a wide variety of content.

It is not acceptable to let each implementation and application choose its own vocabulary. Interoperability suffers, and software complexity increases. Common concepts should be expressed in common ways across the entire spectrum of applications.

Large-granularity features are better

The temptation to do fine-granularity negotiation between sender and receiver is high, but ultimately, no one is served well by it. Adapting content exactly for the color gamut of the receiver or for the details of the font repertoire may be necessary, but as a community the pressure should be on the receivers to adopt complete solutions or, miniminally, have clear predetermined fallbacks. The general experience has been that fine-grained detailed content adaptation is problematic and difficult to support and sustain.

Personal History

I have been involved in the development of web standards since nearly the beginning of the web, contributing to the development of the fundamental standards underlying the web. I have worked in the area of content negotiation and content adaptation even longer; beginning in the late 1980's with a content management and adaptation system called "System 33"; System 33 was influential in the development of content negotiation in the web architecture (see this 1992 report, for example). Among other work, I helped establish the CONNEG work within IETF (as a spin-off of work in the HTTP working group), and contributed to it and related standards.