MFD WG,
Sorry about these questions so close to the holidays, but I would like to
solidify the meeting comments before they are lost to our celebrations.
1. With respect to item 1 below, I suggest that a path from Print,
FaxOut, EmailOut to an external repository is valid only if it is a normal
part of the service that a client can extract the document from that
repository. Using an external repository for JobSave, if that digital
document is not normally accessible to the outside world, is an internal
implementation aspect and should not be considered in the model any more
than a Copy Service Digital Document should be. That being agreed, my
question is then whether it is a customary or desired feature of any Print,
FaxOut, or EmailOut Service to allow alternate access to a Digital Document.
2. I am confused by several comments in the minutes relative to
operations, and admit that I was working with the document at the time they
were discussed so did not digest the discussion at the time. The comments
start on line 84 of the minutes and deal with Table 49 and the following
text.
a. Add "comma" between all parameters.
(no problem)
b. Get<service>XXXElements: Pete proposed the semantics of these
operations to be taking the requested element name (the keyword of the
top-level elements) as input, and returns one selected top level element
group elements (e.g. capabilities, default ticket, . etc., of a service) .
One exception is that the MediaCol element is quite large and thus the
elements of this group are not returned for Capabilities group. A single
element can only be returned by adding an extension operation. Pete will
align the current Print Service with this semantics.
Does this mean:
. The parameters supplied with the Get<service>DocumentElements,
Get<service>JobElements and Get<service>ServiceElements operations must
include "Top-Level" elements?
. What are the "Top-Level" elements? The original writeup
identified DocumentReceipt, DocumentStatus or, DocumentTicket; JobReceipt,
JobStatus, or JobTicket; and ServiceCapabilities, ServiceConfiguration,
ServiceDescription, ServiceStatus or DefaultJobTicket.
. Can only one "Top-Level" element be included in one request? This
is implied in the original writeup but not clearly stated.
. The "exception" for MediaCol is disturbing. Are we to simply say
that all complex elements and constituting elements except MediaCol and its
constituent elements are reported?
i. All
Services must align with this semantics. This is the same used in WS-Print.
ii. Bill
will add these statements in the Conformance section.
. The paragraph defining the operation will reflect the semantics,
once we clarify what the semantics is. I do not understand "ii". The
Conformance section, as revised, requires that the Service Specifications
use the definitions in the Overall document. The Overall document does not
specify the conformance requirements of any Service.
c. Set element - should be able to set a specific element
i. Set
uses sparsely populated tree (only contains element values to be set). IPP
specifies that "this must be an atomic" operation.
ii. Get
element: The client can obtain a specific group of elements. (not IPP
semantic, a WS-scan semantic).
iii. Bill
will resolve offline with Ira's comments.
. It is unclear to me what I need resolve with Ira's comments. I am
concerned however about the semantics of all of the operations ,
particularly the response. I would assume that the response to a GetElements
would include an identification of each simple element falling somewhere
under the "Top Element" and its value. Would complex element names be
returned?
Thanks!
Happy Holidays!
Bill Wagner
From: William Wagner [mailto:wamwagner at comcast.net]
Sent: Thursday, December 17, 2009 10:28 PM
To: 'mfd at pwg.org'
Subject: RE: [MFD] Dec. 8-9 Face-to-Face Meeting Minutes is now available
Nancy and MFD WG,
Many thanks for your extensive minutes. However, I wonder about a few of
the Items.
1. With respect to the comment relative to Figure 2 of the Overall MFD
spec, line 47 in the minutes:
o There should be no data flow arrow from print to Repository - the second
digital-doc is for job save operation.
It was my understanding that that path was to be retained and was indeed
associated with job save.
Of course, the diagram (perhaps more for clarity) shows a two
repositories: one that a client inputs to and that provides documents to
Services; the other that Services input to and that make document accessible
to clients. One could argue that Services (other than Transform) that
receive digital documents and potentially store them for some later action,
but not for local client re-access in a digital form should show the data
flow arrow back to the "input" respository. In that case, I suggest that
Print, FaxOut and EmailOut should shown the document storage path back to
the "Input" repository. Also, although I am a bit shaky on the EmailIn/Out
Services, I suspect that EmailOut should, like Print and FaxOut, have a
potential input from an input repository. Comments?
2. Line 51 in the minutes: There is no document ticket, only job ticket
containing document processing instructions. I had noted not to indicate
that a job may contain a one or more Document Tickets. But if a Job cannot
contain any Document Tickets, I wonder where document tickets get associated
with the documents in a job?
3. The resolution of StorageMakeAndModel reference is not noted. I
recall a reference to the HR MIB and the Printer MIB, but I can find this
object in neither.
4. Also, as noted in the minutes, there are items that Pete and Ira have
yet to supply.
Thanks,
Bill Wagner
From: mfd-bounces at pwg.org [mailto:mfd-bounces at pwg.org] On Behalf Of
Nancy.Chen at okidata.com
Sent: Wednesday, December 16, 2009 10:30 AM
To: mfd at pwg.org
Subject: [MFD] Dec. 8-9 Face-to-Face Meeting Minutes is now available
All,
The minutes is now available at the following links:
ftp://ftp.pwg.org/pub/pwg/mfd/minutes/pwg-ftf-mfd-minutes-20091208-09.pdf
and
ftp://ftp.pwg.org/pub/pwg/mfd/minutes/pwg-ftf-mfd-minutes-20091208-09.doc
Thanks for all the participants!
-Nancy
----------------------------------------------------------------------------
----
Nancy Chen
Principal Engineer
Solutions and Technology
Oki Data
2000 Bishops Gate Blvd.
Mt. Laurel, NJ 08054
Phone: (856)222-7006
Email: Nancy.Chen at okidata.com
--
This message has been scanned for viruses and
dangerous content by <http://www.mailscanner.info/> MailScanner, and is
believed to be clean.
--
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/20091218/8be5a3b3/attachment-0001.html>