[Cloud] Cloud Imaging model requirement draft

[Cloud] Cloud Imaging model requirement draft

[Cloud] Cloud Imaging model requirement draft

William A Wagner wamwagner at comcast.net
Sat Apr 20 17:22:57 UTC 2013


Larry and Michael, 

I do not see either the rational or advantage in separating the Cloud
Imaging Service in the model into separate Service entities. The Semantic
Model is constructed on the basis of an MFD, which can support any one or
more of the imaging services.  I do not understand why this model does not
hold equally when the path goes via  a Cloud based server.


A Cloud Model that has a Cloud Imaging Server, with which the Client
interfaces using  the sort of operations defined in the Common Semantics
document (e.g., Create<service>Job ) and with which a Cloud Imaging Manager
interfaces using the "reverse" set of operations (e.g., Fetch<service>Job)
is neither inconsistent with the SM nor an unreasonable model. 


The existing Semantic Model provides a uniform way in which an imaging
device or a set of software appears to interfacing entities. Defining
separate 'services' is a functional rather than physical division. The
semantic model  did not define separate servers.  The reason the service
specifications were separate was for the very practical consideration that
getting one complete spec  written and approved would have been an even
longer and difficult task, and there was concern  that members and their
companies would lose interest. Specifying some services before considering
the common model, and documenting the common model before the nature of each
of the individual  services was considered did, as Mike indicates, result in
some inconsistencies that need to be rectified. I do not agree that this
resulted in each introducing a slightly different version of the common
schema beyond what was inherent in the specific nature of the service. I
think it worthwhile for the Semantic Model group to consider a single Common
Model update that includes each of the individual services, and I think we
should discuss this both for its conceptual preferability  and in terms of
resources.


 

An overall Semantic Model  document may be divided into common, document
input and document output  services in the discussion; that should be
considered in formatting the document. But I question whether the model
itself should be collapsed. With respect to defining a Cloud
Scan/FaxIn/EmailIn service that provides  storage,  it is unclear  why this
is preferable to a Cloud Imaging Service that includes Scan, FaxIn, EmailIn
and Resource functional services (as well as the other Imaging Services).

 

In short, I understand that there may be valid alternate solutions that
appear, to some, to have advantages over the current one. But we have an
approach that is not broken and  into which a lot of effort has been
invested. I suggest that we need consider very carefully  before we take off
on a different route.

 

Larry, in an effort to continue keep Cloud modeling going, I propose to
update sections 1-3  of  your wd-cloudimagingmodel10-20130206.docx  with the
additional changes that have been discussed over the past few months in
regard to the Cloud Printing Model. Please let me know if you prefer a
different approach.

 

Thanks,

Bill Wagner

From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
Michael Sweet
Sent: Friday, April 19, 2013 3:59 PM
To: larryupthegrove
Cc: cloud at pwg.org
Subject: Re: [Cloud] Cloud Imaging model requirement draft

 

Larry,

 

On 2013-02-07, at 2:38 PM, larryupthegrove <larryupthegrove at comcast.net>
wrote:

 

I posted a draft of the Cloud Imaging document to the white folder of the
FTP site.  Please review the document and determine if you think this is a
reasonable way forward, or suggest alternatives.

 

Thanks for this, and apologies that it has taken me this long to review
it...

 

... 

I would as a next step create the framework for the Fax and Scan model
documents by using the Cloud Print Model Requirements as a master.

I believe there could eventually be a Copy and a Device Administration set
of requirement documents as well.

 

 <ftp://ftp.pwg.org/pub/pwg/cloud/white/wd-cloudimagingmodel10-20130206.pdf>
ftp://ftp.pwg.org/pub/pwg/cloud/white/wd-cloudimagingmodel10-20130206.pdf

 

 
<ftp://ftp.pwg.org/pub/pwg/cloud/white/wd-cloudimagingmodel10-20130206.docx>
ftp://ftp.pwg.org/pub/pwg/cloud/white/wd-cloudimagingmodel10-20130206.docx

 

One problem I see with this approach is that the Semantic Model WG did this
and now has a bunch of specs to update to synchronize with a 2.0 common
model document.  Each new service has introduced its own slightly-different
version of the common schema.  I would rather we not go down the same road.

 

Generally speaking, we need to address document output (Print, FaxOut,
EmailOut) and document input (Scan, FaxIn, EmailIn) services that are
accessed via a set of Cloud/infrastructure services.  All of the current
work has been focused on output, and I think we are in a good place there.
For input, we need to extend the Semantic Model slightly to have the Cloud
Scan/FaxIn/EmailIn service provide a storage location (FTP or HTTP/WebDAV)
so that the Manager has a place to store the incoming documents and the
Client has a place to retrieve the incoming documents.

 

Transform is the classic "in the cloud" service, and I don't see a need to
define a separate Cloud interface to support a situation where a Client
submits a Transform job to a Cloud Transform Service, to have that transform
be performed on an imaging device - doesn't make a whole lot of sense.

 

Copy can be modeled as Print with an AddPrintHardcopyDocument operation.  If
we *did* keep a separate Copy service, it is just an output service that
does not fetch or acknowledge documents.

 

Device Administration is out of scope.  We are not defining an interface for
remote device management.

 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

 


-- 
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/cloud/attachments/20130420/f7382ca2/attachment-0002.html>


More information about the cloud mailing list