The problem is that media is really a collection of attributes and the
correct way to handle it is to return the collection. Yes, the long string
is ugly and probably problematic to parse. So, I would prefer returning
an XML collection including a shortname. The XML collection should contain
of the relevant info (size, printable area, color, double ply, ...).
The problem with your suggestion is that (A4, letter, ...) are not unique
for additional queries or selection. It is also missing important info
such as this form is only available in the manual tray. Yes, we could do
a long series of additional queries to drill down (Ok, I want letter, tell
me what colors are available, Ok I want blue, tell me what trays it is
available in, woooops it's only available in the manual tray. OK, tell me
again what colors are available for letter, OK, I want pink, tell me
what tray it is available in, wooops again. The reality is, to make
sense of this data it must be returned as a collection or I must do a
multitude of queries to build the collection. To date, I have not found a
protocol that correctly implements the queries so that the constraints
between choices can be accurately represented. Also, the long sequence of
queries have proved to make usage extremely slow.
Rather than risk that protocols using this spec get it wrong again. We
should just define the collection and move on.
I laughed at don's TP example since even after he have me the long string
of attributes he forgot to tell me what wall the paper was on. So, he
didn't get any paper or he got the default tray which has sandpaper.
Regards,
Mark VanderWiele
IBM, Linux Technology Center
512-838-4779, t/l 678
MARKV at IBMUS
email: markv at us.ibm.compmoore at netreon.com on 05/01/2001 07:27:51 PM
To: "Wagner,William" <wwagner at netsilicon.com>
cc: "'Hastings, Tom N'" <hastings at cp10.es.xerox.com>, "Bergman, Ron"
<Ron.Bergman at Hitachi-hkis.com>, Harry Lewis/Boulder/IBM at IBMUS, "Don
Wright (E-mail)" <don at lexmark.com>, IPP Group <ipp at pwg.org>, Norbert
Schade <norbertschade at oaktech.com>, Mark
VanderWiele/Austin/IBM at IBMUS, "'RonBergman at aol.com'"
<RonBergman at aol.com>
Subject: RE: IPP> global media; comment on yesterday's proposal [put units
field last]
I know I havent contributed much lately and apologize if I am rehashing
arguments that have already been covered.
Why does the name have to include the size - my name doesnt include my
telephone
number, if somebody needs my phone number they look it up using my name as
a
'key'. Surely the correct solution is to allow a device to assign any name
it
likes to media (probably choosing well known ones for its market, B3,
Letter,
....). If the client app /driver needs to know the physical size then all
that
is needed is an operation to query the paper size, the response must
include the
units. Likewise the app more than likely needs to know the markable area -
it
should be provided with a mechanism for asking for that information.
Similarly
if you need to know the color, thickness, manufacturer, weight,
permiability,
date of purchase, etc. there should be queriable attributes to read these
things; lest we end up with don's
na_toilet_paper.continous.landscape.ruffled.4_4in.offpink.clockwise
Which tells you everything except the markable area and the manufacturer
If a device has more that one A4 available (say), then it can invent names
for
them (or even be operator assigned). To support this case there should also
be a
'standard name' attribute that can be queried - this would return A4,
legal,
ASMEY14,...