Run-time Policies: The Media Policy Description Language

  We have chosen to implement the policy of degradation at run-time for the following reasons:

• The underlying technology has four main methods through which the implementation of the transferred media can be manipulated. The application thus has at least four degrees of freedom in which we can change the implementation, and so providing a wide choice of trajectories of degradation.
• The application using the media is very generic - the Web model of documents is being pushed by Microsoft as others as the basic metaphor for the next generation of machine interfaces. Since the uses of the application are legion, we as designers cannot constrain the choice of policy degradation.
• The ability to transform the media entirely across types implies an even wider implementation space. Since transformations may be chosen as more convenient by the user, eg. a partially sighted user may transform text to audio, we believe that allowing users to determine policies of adaptation will provide more exciting use of the technology.
• In downloading a particular media instance, there are two associated actors who are interested in how the media is downloaded and displayed - the person initiating the download and the author of the media. Each of these actors may have preferences about how media should arrive - users may want download as fast as possible, yet authors may require a colour display. To allow each of these actors to define requirements, it is easier to resolve run-time resolution of policies..

Policy degradation objects are written in the Media Policy Language mpl and are interpreted within the application and the server. They can be combined with each other to form new policy objects representing the combined needs and experience of user, author and system designer.

The policy objects have been used to control the preferences users have in how images are viewed across the Web. However, the principle applies equally to other multimedia application (networked or otherwise) and indeed to any application that wants to scale it's interface. User, authorial and default policies could be devised to allow an application's widgets to present themselves in a sensible manner on differing platforms and visual displays.

The mpl is a rule based language that allow the mapping of certain actions or mutations to specific groups or subgroups of media according to the various current networking and display conditions.

The general format is:

path : condition : action [, submission]

Path means apply action to the specified media type if the condition is true and some rule belonging to a different rule group doesn't override the path. Conditions are legal boolean expressions.

We use environment variables to hold values of networking and display conditions and attributes of the media, as determined by the run-time environment [19]. Each environment variable has a unique name and has a type. Currently variables are:

FILESIZE       - int
MEDIA-HEIGHT   - int
MEDIA-WIDTH    - int
MEDIA-DEPTH    - int
DISPLAY-WIDTH  - int
DISPLAY-HEIGHT - int
DISPLAY-DEPTH  - int
BANDWIDTH      - int    (in Bytes/second)
RATE           - int    (flow rate for streams eg. frames per sec)
MIME           - string (mime type of media object)
META           - string (used for passing any other info)

Actions are compress (lossless), reduce (quality: lossy compression), scale (Dimension), and transform (from one media to another) etc, as in Table 1.

For instance, if a user wishes to compress all objects over 10k

media.* : SIZE >= 10*1024 : compress;

or if a user has a monochrome browser

media.image.* : true : toMono;

or for a more complicated expression when the browsers is always used over low bandwidth links.

media.image.jpeg : meta(progressive) == false : 
        toProgressive, submit default;
media.* : true : scale 75, submit author;
media.* : true : reduce 50, submit author; 
media.* : true : compress 10;

Policies can be combined with information to the environment to select paths of degradation depending upon the available constraints, so if the user wishes to ensure that all download times are less than five seconds, they first attempt to reduce the quality, then if this fails, they scale the object, using the resolution process in Section 5.1,

media.* : SIZE/BANDWIDTH>5 : reduce 50;
media.* : SIZE/BANDWIDTH>5 : scale 75;
media.* : true : compress 10;

An author's policy to make sure that a JPEG fits in the available space:

media.image.jpeg."www.site.org/pics/mypic.jpeg" : 
        MEDIA-WIDTH > DISPLAY-WIDTH : 
                scale (MEDIA-WIDTH / DISPLAY-WIDTH);

• Policy Resolution