Meeting notes from the UPDF meeting in
New Orleans, November 8th 2002.
Attendees
Bob Taylor, HP
David Hall, HP
Jim Sommer, Granite Systems
Mabry Dozier, Minolta, with two other developers
Peter Zehler, Xerox
Geoff Sword, SW2000
Norbert Schade
Over the last weeks we have been carefully watching the directions of the Semantic Model. Major concerns have been that this is only the XML version of IPP. We acknowledge that Peter Zehler and other people have put some great effort into establishing a set of schemas, which can be used as a basis for quite a variety of standards within the Printer Working Group and perhaps other related activities outside the PWG.
As the UPDF group was the first group within PWG to define their rules in XML we walked ahead and developed XML schemas representing our requirements. As our goals are different to the ones of IPP and other groups, we had and have to make our own decisions. Fortunately the Semantic Model has become more open and very engaged to represent the basic needs for all printing related standards. Jim and I joined the Semantic Model meeting on Thursday and learnt more about the available schemas and the concept behind them. Some discussions reached even into our UPDF meeting and we are checking these days, how much effort an adaptation at least up to some degree would cost, how many of the structures and data UPDF needs are available in the Semantic Model and how open the group is to add or modify the SM schemas due to our requirements. Peter showed up in our meeting as well and he is very cooperative.
Another group we are in close touch with lately. In New Orleans some HP developers presented a new capabilities schema. They claim it is a schema, which can be used to create flexible structures of Semantic Model elements and data types to describe various aspects of MFP devices like printing and other services. As we are very interested in synergies between the different activities within the PWG and the people of the PSI group are eager to work out a common solution, we are investigating this direction as well these days. We have acknowledged that UPDF and PS share a large number of goals, while some sections are very UPDF specific. Samples of the latter could be composite features with all the implementations, user policies, device fonts or device configuration, but certainly the event handling with all the command sequence and print parameter management in the background.
The fact that we could set our mind to the larger picture lately shows that we have solved many of our UPDF specific problems by now.
Jim Sommer could show a UPDF implementation under Windows, which demonstrated how composite features including UserExtensible and Dominant attributes in combination with user policies can work. In spite of its complexity and depth this explained the design of our structures very well. He may place some set of files to the UPDF web site soon. This will not be a final implementation and for demonstration purpose only.
All UPDF schemas and XML files show a MIT license lately. Harry mentioned that this is different from other standards and will check consistency requirements.
Following a general experience we share with other PWG groups we will not use different namespaces within one standard. The required design goals can be accomplished by simple includes as well.
We have simplified the way command sequences and printing parameters are specified. I will refer to that in a separate email. We have changed the schemas and instance files appropriately and will copy them to our web site the next days after having reviewed some editing mistakes. The main change is the implementation of wildcards and referring to unique command elements, which eases the implementation in drivers. This is the reviewed design: First check the events for references to command sequences (unchanged). Second identify the referred command sequence in the according XML instance and check for variable parameters. This was not easy before. We even had cases where a reference to specific Command elements was almost impossible. Therefore we decided that we need unique elements with unique names to refer to. One of them (the Parameter element, previously the Command element) is predefined as single, optional by the specification. Others can be added by the printer manufacturer if needed, but is not considered the usual case for most parameters. Once having unique elements we do not need an attribute CommandSequence_ID in that element any more, but only a Parameter_ID. The third step is still that the feature records (like MediaSize_Record) provide the final reference back to the Command Sequence instance to resolve it completely. This step is unchanged as well. As I said more details and samples separately.
We have added an attribute to re-use dependencies multiple times with different actions depending on which feature mentioned in the condition was used last. This should help keeping the definitions of dependencies compact without loosing the simplicity of parsing.
We presented some ideas of the implementation of a description how manual duplex can be realized on various printing devices. It seemed that the discussions before had used up most of the energy and everybody was quite tired by then. So we will have this discussion on the reflector soon.
We will not meet in Hawaii. But we may have at least one f2f meeting with some folks from PS and may be Peter Zehler during the upcoming weeks. We will keep you updated on that.
Norbert Schade