attachment-0001

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4611.1300" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2>In L.A. we agreed on a redesign of command sequences and 
parameter handling.</FONT></DIV>
<DIV><FONT size=2>While we still are dedicated to the&nbsp;earlier directive to 
k</FONT><FONT size=2>eep the real command sequences and parameters out of the 
technical device description and gather it in a separate file.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>But over the time we learnt that we cannot predict the number 
of parameters needed in every case. Predefine them as ComSeq_Parameter_1, ..._2, 
etc. was not the optimum solution either.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Secondly we are facing features (e.g. Raster grahpic), which 
require dealing with more than one command sequence. Predefined element names 
don't look promising here neither.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>A third argument was brought in that the management of command 
sequences is inconsistent, as sometimes driven by features, sometimes by 
events.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Ok, that was valuable feedback. And we worked it 
over.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Now the management of command sequences is 
strictly&nbsp;initiated by events. The events describe the print stream and 
therefore refer to command sequences at the proper place.</FONT></DIV>
<DIV><FONT size=2>If no parameters are needed (like an init: &lt;esc&gt; E), the 
reference can be resolved in the command sequence xml file. The corresponding 
schema is now split into two sections: CommandSequences and Parameters. Both 
sections can have a practically indefinte number of elements CommandSequence_ID 
respectively Parameter_ID. As there must be exactly one leading element per 
schema, we define one: Commands. This one has the two sections 
underneath.</FONT></DIV>
<DIV><FONT size=2>If parameters are needed, they can be referred to within a 
command sequence, where you can point to a feature. This feature will have to 
provide a Command element with an attribute CommandSequence_ID, which will show 
exactly the same reference as&nbsp;originally in the event and serves as an 
identfier for the correct command sequence, and another 
attribute&nbsp;Parameter_ID, which&nbsp;is resolved in the Parameters section. 
This way we can easily manage more than one Command element, as we can identify 
them.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>See the schema and samples flying in tomorrow. I'm working on 
that right now.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Norbert Schade<BR>69 Prescott Drive<BR>North Chelmsford, MA 
01863<BR>978-251-1017<BR><A 
href="mailto:norbertschade@mediaone.net">norbertschade@mediaone.net</A></FONT></DIV></BODY></HTML>