Some forms even have 'hidden fields'. Maybe there's a description of
some of the form elements, too. There's a natural conversion from
"form" to "HTML form", and vice versa.
Let's imagine we have lots of kinds of forms, in fact: PDF forms, HTML
forms, and maybe a new kind of form which is a "simple form".
Let's suppose that job setup for printing consists of
a) get the form for this virtual printer
Unless you say otherwise, the form you get is
a simple form. (forms can be cached, getting
the form for a virtual printer seems like it fits HTTP).
b) assume that ONE of the parameters of the form is
the "file-to-be-printed".
Then "submit print job" consists of "fill out form" and then "submit
form" (send the form data to the address given by the Action).
This actually fits nicely into HTTP-as-it-is. You don't need new kinds
of URLs, and, if you're willing to live with HTML forms (or perhaps a
stylized subset of them), you can both use a custom client and also a
standard browser to do job submission.
There's an operability issue of whether the form is filled out before
the application prints, or at the time the application starts to
print.
Maybe there are two forms, one for "generic setup" and another for
"particular job", and the printer gets to decide how the form data
gets split between them. The "generic setup" form is available from
"Page setup".
To get a good GUI for printing, you might need more form widgets
than are available in HTML, or at least some way of annotating them.
A printer could offer multiple kinds of forms, e.g., one for Java, one
for HTML, and one for simple clients.
Printers with lots of features would have complicated forms. Content
negotiation could allow the growth of custom kinds of forms with
access to printing functionality to a ubiquitous view of how forms get
filled out.
Larry