On 2013-04-21, at 9:53 AM, Paul Tykodi <ptykodi at tykodi.com> wrote:
> 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.
Paul,
Read both of my messages again please. The current model requires the Client to supply a destination URI for the scanned/faxin documents. There is no notion of retrieving/fetching a document for those services - only the resource service does that (but it is not job-based).
The issue is this: how does the Client provide a destination URI that is accessible to the Manager? It can't be resident on the Client (the typical solution today), And there is no way for the Client to discover whether the Service provides storage, or at what URI. Since the Service (i.e. the Cloud Service) is an entity that both the Client and Manager can access, it makes sense for us to define a way for the Service to advertise/support automatic destination support such that the Client can rely on the Cloud Service to hold the documents it wants to scan, documents that have been received via Fax, etc.
> ...
> 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.
I don't believe I have made any such suggestion.
What I *have* done is pointed out a few issues that specifically affect the definition of Cloud Scan/FaxIn/EmailIn/Transform but that are also issues for traditional, non-Cloud versions of those services. These might require some tweaking (new elements, amended semantics) to properly support Service-supplied storage.
I have *separately* brought up questions of what services SM 2.0 should include, pointing out that Copy can be implemented in a different way that is more consistent with how FaxOut was defined, and that the Resource service no longer seems to have much relevance. My opinion only, with the view to further unify the various imaging services in SM 2.0.
> ...
> 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?
If the workflow/scripting/orchestration was bridged across cloud services, then yes it would make sense to get at least a straw-man model put together so that we have the pieces in place to support it. However, given that no such model has been created I would suggest an alternative - define the traditional and cloud interfaces for workflow/scripting/orchestration in that new document in SM, based on the work done in the Cloud WG.
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
--
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/d441fc78/attachment-0002.html>