Hi Mike,
I completely agree with Bill's assessment of the Semantic Model work to date
and I believe that it fully supports the efforts of the Cloud Imaging
workgroup without requiring significant changes to its current format.
>From my perspective, it is completely appropriate for the Cloud Imaging
Model workgroup to decide that the presentational format of Semantic Model
elements needs to be adjusted for the specific requirements of the cloud
environment.
There is in my opinion a huge difference between choosing a different
presentational format for information relevant to cloud deployments and
suggesting that because cloud deployment requires a different presentational
format, to best utilize information from the PWG, that we therefore need to
completely reorganize the presentation of the Semantic Model itself. I don't
think that changing the Semantic Model format to be more relevant to cloud
(and potentially less relevant to other environments) is warranted or
advisable.
Different Question - Pete Zehler had mentioned in one of the SM meetings
last year where we were discussing the Transform Service that at the
Semantic Model 2.0 level, we would be allowed to declare workflow in scope
for any SM service. I think this is a very good idea to place into the SM
charter for some of the services. Do you think the additional modeling of
workflow would help with the cloud environment?
Thanks.
Best Regards,
/Paul
--
Paul Tykodi
Principal Consultant
TCS - Tykodi Consulting Services LLC
Tel/Fax: 603-343-1820
Mobile: 603-866-0712
E-mail: ptykodi at tykodi.com
WWW: <http://www.tykodi.com/> http://www.tykodi.com
From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
William A Wagner
Sent: Saturday, April 20, 2013 1:23 PM
To: 'Michael Sweet'; 'larryupthegrove'
Cc: cloud at pwg.org
Subject: RE: [Cloud] Cloud Imaging model requirement draft
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 <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/20130421/78a145a9/attachment-0002.html>