We still have a problem with printer-uri, job-uri, job-id, and
containing-printer-uri. Some statements of fact
1. The client supplied "printer-uri" in a create request MUST be one of the
URIs in "printer-uri-supported"
2. For each new Job object, the Printer object generates both a "job-id" and
a "job-uri".
3. If the client has a only a Job URI the client can query the Job to get
the containing printer URI
4. We DO NOT return the "containing printer URI" in the create response, but
we do return the Job URI and the Job ID. Since we do not return the
containing printer URI, we are assuming that the containing printer URI MUST
BE the same as the client supplied Printer URI.
Here is the question:
Should the Printer object generate the "containing-printer-uri" for a new
Job object or should the Printer object use the client supplied
"printer-uri"??
Or stated another way:
Should the "printer-uri" that a client uses on a create request be the
"containing-printer-uri" or should the Printer object choose the value for
"containing-printer-uri" which might be different than the client supplied
printer URI in the create request?
Some poeple have suggested that we should allow flexibility and allow the
containing printer URI to be different than the original printer to which
the create request was supplied. However, this would mandate:
- ALWAYS returning a "containing-printer-uri" whenever the "job-id" is
returned (create response, get Jobs query, query Job). We would never allow
a client to get ONLY a job id. It MUST always get both since the client
might query a Printer URI for a Job and then it might have to use a
different Printer URI to query the job using the Job ID, so both must ALWAYS
be returned.
- The Job ID has no meaning in the the context of the Printer object being
queried, only in the "contianing-printer-uri" Printer
This seems convoluted. We have this flexibility in the Job URI (where it
should be). We only introduced the Job ID for support for existing APIs. I
am sure that these APIs to not support a Job ID coming back for a different
printer than the one to which the job is being submitted.
I think that the answer to the above should be:
1. The client supplied printer-uri should be the containing-printer-uri
always! A client
can always go back to Printer object to which the job was submitted and use
the job-id.
2. If a client is querying a Printer for Jobs, the Printer only returns job
ids for jobs that are associated with that Pritner URI
3. Leave the flexibility of Job identifiers that are independent of Printer
URIs to the "job-uri" attribute not the "job-id"attribute.
Scott
************************************************************
Scott A. Isaacson
Corporate Architect
Novell Inc., M/S PRV-C-121
122 E 1700 S, Provo, UT 84606
voice: (801) 861-7366, (800) 453-1267 x17366
fax: (801) 861-2517
email: sisaacson at novell.com
web: http://www.novell.com
************************************************************