With your example below, I would expect that the html response could
be a collection of attribute values to display -- the supported values
and each default. The user can then make changes and when the user
clicks the submit button, the client returns a list of values, one for each
field, i.e. attribute.
In the general sense, HTML forms are just another language for describing
a GUI. Any program, including a Web Browser can display an HTML form.
If the program displaying the HTML is something other than a Web Browser,
then users will probably view it as a dialog box and not realize that
HTML is underneath. HTML needs a few more features before it can describe
all the GUI features we might want, but I expect that will happen in time.
So, I think that HTML is quite adequate to handle your job submission
scenario below.
Bob Herriot
>
> Don Wright wrote:
>
> Here you are clearly wrong. Lexmark's MarkVision for
> the WEB is able to provide printer and printer Queue status
> on unmodified, unassisted browsers today. If our scenarios
> and models do not support this mode of operation then a
> grave design error has been made.
>
> RKD> Don, I'm not sure what you mean here. Clearly one can
> RKD> continue to use existing browsers as you have in
> RKD> MarkVision for the web. However, you can't, in my mind,
> RKD> mix the two. For example, the following seems to be
> RKD> difficult, if not impossible:
>
> Client Printer
>
> --------------------------------------------->
> get printer capabilities (IPP request)
>
> <--------------------------------------------
> capabilities (html ala MarkVision)
>
> --------------------------------------------->
> print request, using capabilities (IPP)
>
>
>
>