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 face=Arial size=2>We are talking for some time about limiting our 
specification to certain&nbsp;features like media handling, font handling, 
color, etc., but providing a generic method to add others like EconoMode, REt, 
etc. I call the latter group of&nbsp;features the generic features from now on 
for better identification.</FONT></DIV>
<DIV><FONT face=Arial size=2>We said we would provide a number of fields to make 
the most entries and probably even prepare different structures for different 
groups of features (the simple On/Off features, finishing features like 
stapling/punching with position values, etc).</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>I must say I suffer.</FONT></DIV>
<DIV><FONT face=Arial size=2>I admit I suffer for quite a while 
already.</FONT></DIV>
<DIV><FONT face=Arial size=2>As much as I like the idea to limit the UPDF to the 
most common features and have one more generic feature called 'GenericFeature', 
I don't trust it really.</FONT></DIV>
<DIV><FONT face=Arial size=2>The more I think about it the more I suffer. And I 
have this suspicious feeling in my&nbsp;stomach that we oversee something. As 
some of you know I care alot about my stomach.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Enough joking. I haven't solved all issues around 
the generic features so far. Either we solve it or they will go or we'll buy 
some weaknesses.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>1. Bidirectional communication</FONT></DIV>
<DIV><FONT face=Arial size=2>When it comes to bidi, the driver must detect the 
meaning of a certain incoming feature to make the connection to a driver 
setting. We haven't talked about bidi too much so far, but even if we leave it 
out in the first level of UPDF, I want us to anticipate enough functionality 
that we will not have to change a previous spec when adding new functionality in 
future.</FONT></DIV>
<DIV><FONT face=Arial size=2>I have certain expectations of bidi. I do not 
expect bidi to tell me everything a driver may have or likes to know about a 
certain feature. It is enough when bidi is telling me what of the information 
the driver has already (either compiled or as UPDF) is to be activated. As a 
consequence this may activate a whole group of other information not having been 
passed in. And that's ok.</FONT></DIV>
<DIV><FONT face=Arial size=2>So it comes to keywords and settings. Settings can 
be different things: values, ranges, structures and may be more.</FONT></DIV>
<DIV><FONT face=Arial size=2>The point when talking about generic features is 
that the driver must be able to anticipate, which keywords and settings the bidi 
routine will pass in.</FONT></DIV>
<DIV><FONT face=Arial size=2>Sample: it must know that the bidi keyword is 
EconoMode and not EMode. It must know that the setting is a toggle and not one 
within a range of values.</FONT></DIV>
<DIV><FONT face=Arial size=2>If we do not care about this anticipation, we let 
the whole API between a driver and a communication routine open. That would mean 
we forget about a common API to a communication routine and leave that open to 
everybody's proprietary solution - which is a legitimate way to go. But I am 
still dreaming there will be one common IPP communication routine and one common 
PJL (or whatever) communication routine. That would mean every UPDF would have 
to anticipate the same keywords and settings.</FONT></DIV>
<DIV><FONT face=Arial size=2>So if we find a solution for the bidi problem, I 
feel it must include a spec for predefined keywords and a description how 
settings can come in. Then a driver can understand incoming 
parameters.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>2. Constraints</FONT></DIV>
<DIV><FONT face=Arial size=2>I think this is even more serious.</FONT></DIV>
<DIV><FONT face=Arial size=2>Imagine we&nbsp;generic features and somebody 
implements two instances of them: EconoMode and REt.</FONT></DIV>
<DIV><FONT face=Arial size=2>The element name in the dtd would be GenericFeature 
in both cases. Literally it is not GenericFeature1 and GenericFeature2. 
</FONT></DIV>
<DIV><FONT face=Arial size=2>That's the point. The element names are not 
unique.</FONT></DIV>
<DIV><FONT face=Arial size=2>How would somebody specify a constraint that 
EconoMode=On cannot go with REt=On (forget about the nonsense of the 
statement)?</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>This constraint issue is going wild in my stomach. 
This is definitely a showstopper!</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Please help me out.</FONT></DIV>
<DIV><FONT face=Arial size=2>Norbert</FONT></DIV></BODY></HTML>