Roger,
s/m means single-valued or multi-valued.
In the IPP paper, the # in the parens of each header (and the table
of contents) indictes multi-valued, so you might want to just put a #
for the multi-valued attributes and leave empty the single-valued
attribtes.
In your table idea below, you might just want to have a column of syntaxes
and if the # is included, then you get syntaxes and single vs multi-valued
in one column.
>
>I was going to sit down and write up a similar table of attributes with some
>indication of what was required support for each on the client vs. the Printer.
>I had thought of having four columns (accepted by client, generated by client,
>accepted by Printer, generated by Printer) with a yes, no, or optional in each
>column. Maybe everyone else has it straight in their minds, but I thought this
>would help me understand how the attributes are used better. Has anyone else
>done this already? If not, would you think there would be value in doing such
>a table? I don't mind taking a stab at it, as long as y'all recognize that its
>my educated guess at how each attribute is supposed to work, so it will
>probably have many mistakes.
Sounds like a great idea.
It should be straight forward, since each section indicates whether the
group of attributes is generated by the client or set by the printer.
There is one subletly though, the xxx-used job attributes are set by the
program that creates the PDL, so that should probably be another column
or perhap a different notation in the client column though such
a program can run in the server and set the xxx-used attributes too.
Another column (or grouping in the table is whether the attribute is
a job or a Printer Attribute. Also whether the job attribute can also
be a Job Template attribute.
Go for it.
Tom
>
>