Meeting notes from the UPDF meeting in San Antonio, October 21th 2001.

Attendees

Ted Tronson, Novell

Lee Farell, Canon

Mark Hamzy, IBM

Mark VanderWiele, IBM

Harry Lewis, IBM

Jim Sommer, Granite Systems

Don Wright, Lexmark

Patrick Pidduck, PrinterOn

Christy Wang, SerComm, with a colleague

Boyce Harrison, Minolta/QMS

Norbert Schade, Oak Technology, Inc. 

Meeting considerations

The meeting was considered the most effective one of 2001 by a number of people.

We could indeed solve some issues and more or less close composite features.

We agreed on skipping Hawaii and will meet in April 2002 again, perhaps at Oak’s facilities in Boston.

Depending on work and progress we will have a few tele conferences in between or even meet one day independent from any PWG meeting.

We are confident to finish UPDF, level 1, during the upcoming winter and publish it no later than the Boston meeting. This statement is based on the current input.

We will see how well the standard will be accepted and then think about another level of the standard. We identified a number of interesting areas for extensions, which could keep us busy throughout 2002, but we didn’t spend too much time discussing them.

When to read XML?

The two current host implementations we are working on are relying on binary input. So there are a number of converters used to create a binary data input file from the original XML descriptions. These converters right now are started before installation of a driver/client.

The more the standard reaches a final level, the more we have to watch that part of development.

One of the open questions in that area is whether we can continue to go with the current interdependency structure without an on-the-fly XML parser.

Composite features

This was our major item for the morning.

While composite features are in the schema for quite a while, but not yet activated, everybody was expected to have some basic understanding.

The work requires two procedures.

First the simple assembly of a composite feature, which is the easier part. The schema proposed on the web site was accepted to do a proper job.

We could solve the second part of it, which is dealing with the communication with the operating system/application. In an assembly the main classifying attribute (Predefined_ID, Proprietary_ID) of every component can be overwritten.

We will further add an attribute to CompositeFeature to indicate whether the list of ComponentSet is supposed to be edited (e.g. extended) by the end user or not.

An updated schema and mother sample will be created within the next days and placed on the web site for final discussion.

User policies

Once we had generally finished the design of composite feature our path was free to develop a more detailed architecture for user policies.

We agreed on some issues:

• User policies are separate to all other XML files.
• The system administrator/supervisor will have the chance to create composite features and interdependencies, which extend those of the device description of the printer manufacturer. It is the responsibility of this person to care that the new features do not interfere with the original ones. Detailed syntax to be developed in November.
• The system administrator/supervisor will have the chance to set new defaults. These defaults replace the original defaults. Detailed syntax to be developed in November.
• It is to be discussed whether it will be allowed to change the list of records of existing features (e.g. shorten or extend the list of paper sizes) and how that would be accomplished.

Event handlers

We had another discussion on event handlers.

This will be continued on the reflector.

One of the items was how to handle installable options in events, which can not always be predicted. You will see the proposed solution in the update soon.

Event handlers seem to reach their final design as well, although some items are not finally decided.

The latest statement was a proposal to move all command sequence references away from features to event handlers. That would eventually lead to the chance of a more or less complete description of a print file. A very interesting perspective, but this has to be checked with our current implementations and the longterm direction of the standard.

Watch the reflector for further input.

Norbert Schade