[Cloud] Minutes posted from today's Cloud Imaging WG concall

[Cloud] Minutes posted from today's Cloud Imaging WG concall

Zehler, Peter Peter.Zehler at xerox.com
Wed Jun 19 18:12:19 UTC 2013


All,

The PWG semantic model(V1 2002-2004, V2 2005-present) was written using WSDL 1.1.  Although WSDL 2.0 was released mid-2007 it took some time for the tools to catch up.  Specifically XML SPY did not support it until late 2009 and I used that tool to edit all the WSDL and schema.  The gSOAP tool did not support WSDL 2.0 until late 2012 and I use that tool for advanced prototyping.

While I believe it is possible to create a single WSDL file for both a SOAP and REST binding for simple operations I do not think that is applicable in this case.  The main issue is the lack of a schema language for JSON.  As far as I know it is still only an Internet Draft and has no support in any tool of which I am aware.  XML SPY will convert WSDL 1.1 to 2.0 and it can generate a JSON document instance from an XML document instance.  It cannot create a REST/JSON binding from a SOAP/XML binding.   The only way (read that as HACK) I was able to go from XML schema to JSON schema was to generate Java classes from the XML Schema and then generate JSON Schema from the Java classes. But then again I have not played around in this area in a while.  I think better tools exist now (See <http://www.jsonschema.net/>)

Our service operations are not that complicated but some of the parameters derived from the underlying model certainly are complex.  The automated generation of the entire model, or the most interesting components such as Tickets, Jobs etc., can be done in XML or JSON from tools like XML SPY.  Perhaps the transformation can be automated.  Many of you are probably familiar with Google Cloud Print.  Notice in that API specification the majority of the interesting object's attributes are not included in the specification (See <https://developers.google.com/cloud-print/docs/proxyinterfaces#commonoutput>).  The PWG should provide a complete JSON dictionary for the entire model as well as the REST binding for the operations.  As with all our protocols vendors would be free to subset or extend under the usual constraints.

I would think a text based approach is probably the only approach possible at this time for the REST/JSON mapping.

Pete

Peter Zehler

Xerox Research Center Webster
Email: Peter.Zehler at Xerox.com<mailto:Peter.Zehler at Xerox.com>
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701


From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of Ira McDonald
Sent: Tuesday, June 18, 2013 10:58 AM
To: Randy Turner; Ira McDonald
Cc: cloud at pwg.org
Subject: Re: [Cloud] Minutes posted from today's Cloud Imaging WG concall

Hi Randy,
My mistake here.
When I wrote all the original System, Service, Subunit, etc. classes for
PWG SM 2.0 schema in the PWG WIMS project, I wrote only WSDL 2.0.

I mistakenly thought that Pete has been releasing WSDL 2.0 since then.
If we issued PWG SM 2.0 XML Schema w/ WSDL 2.0, a *lot* of the
heavy lifting for REST and other bindings would be done.
Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:blueroofmusic at gmail.com<mailto:blueroofmusic at gmail.com>
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Mon, Jun 17, 2013 at 10:34 PM, Randy Turner <rturner at amalfisystems.com<mailto:rturner at amalfisystems.com>> wrote:

Hi Mike,


The RESTful mapping specification could be written using WSDL 2.0,  but I don't think we currently  have a WSDL 2.0 schema anywhere...the namespaces between WSDL 1.1 and 2.0 are quite different, and the structure of a 2.0 WSDL looks a bit different than a 1.1.

Ira pointed out that we might be able to use a single spec for both RESTful and WS-* mappings, but I'm not sure if that's going to work - it might - I just haven't seen it done.  IBM has a raft of WSDL 2.0 RESTful specs, but they're ONLY RESTful WSDL 2.0 specs...not a combined WS-* / RESTful spec.

I had a chat with a guy from Google and he indicated all of their web services (public facing) have RESTful implementations, and that the API specification is a very simple text-based document describing the URIs, parameters, and basic operation.  You don't have to know XML, XSD, or WSDL dialect to understand it.

As an example of a text-based (non-standard) spec, the following link documents Google's "search" API:

https://developers.google.com/custom-search/v1/using_rest#query-params

I'm not opposed to using WSDL 2.0, but we may need a WSDL for WS-* and a separate WSDL (2.0) for REST.   I'm still looking into this.

R.


On Jun 17, 2013, at 6:25 PM, Michael Sweet wrote:


Randy,

On 2013-06-17, at 5:25 PM, Randy Turner <rturner at amalfisystems.com<mailto:rturner at amalfisystems.com>> wrote:

...
I also wanted to make sure that the concept of registration ("I want to make my printer available to the cloud") is included -- I'm uneasy with some of the items we've talked about in the past being "out of scope" --  Without registration, nothing happens - there is no "service".  We may need to review a couple of other "out-of-scope" items to make sure we're not specifying an abstract model that can't be instantiated by something "concrete" that actually works.

I think we are all now on the same page WRT registration.  As Glen likes to call it, our focus will be on "device registration" and not on the specific security/ACL implementation details - that will be IDS's bailiwick.  Thus, it will be possible to use the model with any security framework so long as it meets the basic requirements of the Semantic Model and whatever we come up with for requirements of Cloud.


On a separate thread, I would like to "re-introduce" my proposal that we include a RESTful specification as one of our initial mapping documents for cloud imaging.

There was some discussion about how we might document implementing the PWG model with existing cloud solutions - perhaps that could be part of the RESTful binding specification (as an informative appendix)?

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair



--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

_______________________________________________
cloud mailing list
cloud at pwg.org<mailto:cloud at pwg.org>
https://www.pwg.org/mailman/listinfo/cloud


--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, 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/20130619/269618da/attachment-0002.html>


More information about the cloud mailing list