Haven't written that up this way.
As David and Bob asked similar questions from different angles I thought this might be a good opportunity.
How to define a print file
The request to be able to provide parameters for features to be used in print files evolved into support of command sequences and events over time.
Binary terms had to be supported as well as plain text. It was required to specify where in the print file a certain command sequence should appear.
Later another decision was made: The real command sequences as used in PDL and probably job language was separated from the higher level device description, which is supposed to be more human readable. Therefore we created a separate schema for command sequences so that PDL experts could convert one PDL specification to another while keeping the device description almost aside. We did not want to work with gigantic switch definitions. So we attached parameter references to the features.
To be able to do all this in XML we needed a tool we call Parameter Converter. This allows for the definition of binary terms in ASCII, references to keywords and attributes as well as simpel IF/ELSE statements.
A high level description of the envisioned process may look like the following:
1. The driver holds a structure with the non-ambiguous setting of each attribute (means feature in many cases), but is prepared being overruled by the user's application.
2. The driver holds a structure with the non-ambiguous setting of all DRV_ keys.
3. Prepare a Parameter Converter function.
4. Any UPDF core driver is expected to understand all possible events, on start as well as on end of it.
5. When an event occurs for the driver, it checks the event list in the device description and checks all event records with that specific event. It may well find more than one record. They should be listed nicely, but I wouldn't rely on that. The order of records for the same event determine the order of command seqences.
6. For all records of this event: Feed the Parameter Converter with the command sequence of the corresponding XML file identified by the command sequence reference in the event. The other two parameter for the function are the pointer to the two structures of 1. and 2. (that's how I might do, feel free to do it a different way).
Within the Parameter Converter
7. The command sequence may show references to unique attributes (dot works as separator, reference to Parameter is wrong as that's an element but no attribute, reference to ID is wrong as that's an attribute but ambiguous, reference to Parameter.ID is better but still ambiguous, reference to MediaSize_Record.Parameter.ID is fine) or DRV_ keys. The ID attribute will show another parameter reference for a special feature setting, which can then be finally resolved in the command sequence XML file (ResolvedParameters section).
Check next event and start with 6. until done with all events.
Some background info on the Parameter Converter:
It started out as reverse Polish notation, but the request was a more human readable syntax. It should understand either ASCII characters or terms of certain syntax. These terms start with a two-byte format string, which tell about the expected output format. IF/ELSE structures are supported, but I wouldn't rely too much on nesting when developing the XML for a device.
That's what I think. Did I forget something or wasn't clear enough? Ask in detail!
Regards
Norbert
Norbert Schade
69 Prescott Drive
North Chelmsford, MA 01863
978-251-1017
norbertschade@attbi.com
This archive was generated by hypermail 2b29 : Sun Mar 02 2003 - 14:47:39 EST