Hi Ira,
Thank you for your response. I apologize for not using proper capitalization
and non spacing conventions in the email, but I obviously am not
communicating the issue adequately and will leave it open for discussion.
And I wonder about " Document object can only be created *after* a Job
object has been created"
We maintain that services such as Scan output Digital Documents to a
repository, in which case the I would assume that the Documents can exist
long after the Job and Job history are gone. And if a PrintJobTicket were to
reference a Document in a repository, are we saying that it is not a
Document until the Print Job is created, which occurs after the Print Ticket
is accepted by the Print service?
Are we (or just I) getting mixed up between the formalities of the Schema
model Document object and the common perception (that we also seem to adhere
to) that Documents are created, shuffled around, stored, and may be included
in a Job.
Bill Wagner
From: Ira McDonald [mailto:blueroofmusic at gmail.com]
Sent: Tuesday, January 05, 2010 5:07 PM
To: William Wagner; Ira McDonald
Cc: mfd at pwg.org
Subject: Re: [MFD] Dec. 8-9 Face-to-Face Meeting Minutes is now available
Hi Bill,
My replies are inline below.
Cheers,
- Ira
On Tue, Jan 5, 2010 at 4:35 PM, William Wagner <wamwagner at comcast.net>
wrote:
Hi Ira,
Quite so. But I had not entered these questions as answered since the
responses did not appear to resolve my questions.
1. Since from your response, a document may contain zero or one document
ticket, and a job can contain zero or more documents, I do not see the error
in saying that a job can contain zero or more document tickets. At any rate,
for those who have not internalized the model, it does answer the question
of how the document tickets get into the service.
I may misunderstand, but I think it would be misleading to say in the
general document description that a document may contain zero or one
document ticket since documents can exist exclusive of jobs, but I assume
that it is only when a document is part of a job that it may contain a
document ticket.
<ira>
When using the correctly capitalized terms for
the SM *objects*, a Document object can only
be created *after* a Job object has been created
and the DocumentTicket object is optional (and
rarely used) to override the JobTicket object in
the Job object.
There is no such thing as a *lowercase* document
ticket in the Semantic Model.
</ira>
2. Your response with regard to StorageMakeAndModel, although it appears
to confirm my observation, does not address the question of what the
reference should be. We originally had two separate elements but there
appeared to be consensus that a single MakeAndModel element was
reference-able. I do not recall who maintained that, but if that is so, I
would like the reference.
<ira>
There is no possible public MIB general reference
for MakeAndModel (which was inherited from IPP
in SM/1.0 and was for whole Printers only).
IETF Host Resources MIB only supports ASN.1
OIDs in the ProductID textual convention used
in hrDeviceID (and elsewhere) for manufacturer
and model - these OIDs cannot be meaningfully
converted to human-readable values for make
and model.
By very loose implementation convention, most
imaging device manufacturers use sysDescr
and/or hrDeviceDescr (for hrDevicePrinter) to
include human-readable make and model - this
information cannot be parsed reliably - I have
had a long thread with HP WJA developers on
this issue.
An IEEE 1284 Device ID does include make
and model, but a separate string (at least for
the whole network device) is redundant.
For *only* two of the subunits (InputTray and
OutputTray), Printer MIB v2 includes make
and model. So there's no public MIB source
for make and model of any other subunits.
The SM/2.0 MakeAndModel element is synthetic
and does *not* have any public MIB reference.
Whether this element is a good idea is really
questionable, IMHO.
</ira>
Thanks,
Bill Wagner
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/mfd/attachments/20100105/654f1c17/attachment-0001.html>