December 4, 2000

The few weeks between Boston and San Diego were formed by a complex update of the UPDF web site as well as some ongoing print media discussions.

It’s good to see that the basis is getter wider and more people are getting experts in a number of sections. So this time we could discuss the issues on a quite high level without loosing to much time explaining things.

As the UPDF group will skip Hawaii, we’ll have some time for implementing the results and changes in the DTD again. We will need all the time until the March conference in Florida for that.

Our current target is to have all major and most of the smaller problems solved in the April’s conference. The major concern for that from today’s point of view is the color management.

Major items discussed

• It turned out soon that one of the main requirements of the day was to have common reference lists within the Printer Working Group.
  Our sample of the day was a list of keywords for print media sizes. Printer drivers need to detect media sizes and have to announce OS specific keywords in a number of cases. There are already a number of standards in use. The UPDF group is unanimously requiring that one common standard will be used in all subgroups like IPP and IPPFax. As the members in the UPnP group are widely the same, we would like to see them included as well.
  This would allow much easier coding to convert between different standards and/or explore keywords from numeric values.
  We see that IPP has a proper list of keywords, which just has to be extended to some degree. We would agree considering the result as a common reference list, if we can reach the required level.
  The UPDF group is willing to contribute to that work. Contacts are Norbert Schade and Jim Lo.
• We discussed some issues on print media handling like the specification for custom sizes and ‘infinite’ sizes (see banner rolls). This has to developed in detail the next weeks while implementing it into the format step by step.
• Then we started the discussion of a new and important issue, which is considered the fourth column of the architecture for quite a while.
  It is named CompositeFeature for now. The name may change the next weeks.
  The requirement for that feature is that a driver not only needs single features in many cases, but also has to be able to define a set of feature as a group, while certain settings of the group features can be saved under a name string.
  Samples where to use this feature are as driver defaults, for forms handling, to represent settings of a complete subdialog one level higher, etc.
  After having defined the group it is a second question whether and how the single members of the group are represented.
  Once defined a CompositeFeature acts as any other feature.
  We agreed on the general specification of this new feature, while some details will have to be cleared during implementation the next weeks.
  I’m not sure whether we’ll have all aspects checked in Florida.
• The main part of the afternoon was then covered by something we call ‘UPDF user interface policies’ so far.
  This is a separate dtd. It does not change the original technical dtd for the printer description at all. But this is a layer on top. The target developer for XML files based on this special dtd is really somebody like a system administrator (SA) for departmental printers of an enterprise, no more the printer manufacturer developer, although he might act as a consultant at the beginning.
  The SA has the chance to define new composite features, filters and new constraints.
  In the extreme he/she could decide to define one composite feature, which represents all others and pre-save two entries ‘Simple Letters’ and ‘High Quality Documents’.
  He could as well decide to hide all other features in the user interface. This would create some kind of extremely simplified UI for general use. This kind of profile would be sent to a number of users together with the installation of the driver.
  Other scenarios is not to hide features completely, but filter out some values or create very customer specific constraints to establish limited access to a printer for a number of people.
  This needs some more work on the details. But if we can provide some kind of generic profile, which can be edited by people like SA, without specific coding for each single requirement, we are very convinced that enterprises will be excited about that.
  I’m not sure whether we’ll have all aspects checked in Florida.
• Generic Features.
  We agreed that some features like print media size have to be predefined features, while others like an EconoMode feature is a more general one, where the driver does not really have to know about the meaning. It’s enough to know how to deal with it.
  We will clean the current format from these features and provide them by a generic feature.
  All to be done within the next two months.
• File structure of the UPDF DTD files
  This still is and will be occupying us to some degree.
  We agreed to make more extensive use of the possible modular dtd structure and to split the include dtd files into smaller units.
  We further agreed that still each XML file will be checked by one dtd file, so that there is a continuous validation ensured.
  The proposed time slice for that work is before the March conference.

Naming conventions:

Constraints are used in different meanings in the industry. To avoid misinterpreting as much as possible we will talk about interdependencies between features instead from now on. Constraints is more reverved to tell about a list of available parameters. Be patient with our learning curve.

prepared by: Norbert Schade