From scaekenberghe at common-lisp.net  Sun Oct  2 11:51:30 2005
From: scaekenberghe at common-lisp.net (Sven Van Caekenberghe)
Date: Sun, 2 Oct 2005 13:51:30 +0200
Subject: [cl-soap-devel] XSD Templates
Message-ID: <DF8905DC-BF1D-4B8C-87D1-BD7D01DE2D40@common-lisp.net>

After struggling with the XSD typing system for some time,
I think I finally 'solved' the problem (as far as the way Google is  
using XSD for their AdWords API).

Internally, a WSDL document is parsed.
Inside the WSDL <types> tag, a XSD <schema> could be embedded.

The parse-xsd code turnes the supported XSD tags into a CL object model.

Before using that model, it is simplified by transforming it into a  
so called XSD template.

Such a template looks like this:

(1
"getAllAdWordsCampaignsResponse"
(+ "getAllAdWordsCampaignsReturn"
     (1 "id" :INT)
     (? "name" :STRING)
     (? "status" :STRING)
     (? "startDate" :DATETIME)
     (? "endDate" :DATETIME)
     (? "dailyBudget" :LONG)
     (? "optInSearchNetwork" :BOOLEAN)
     (? "optInContentNetwork" :BOOLEAN)
     (* "campaignNegativeKeywords"
        (1 "id" :LONG)
        (1 "adGroupId" :INT)
        (? "exemptionRequest" :STRING)
        (? "criterionType" :STRING)
        (? "language" :STRING)
        (? "status" :STRING)
        (? "negative" :BOOLEAN)
        (? "destinationUrl" :STRING)
        (? "type" :STRING)
        (? "minCpc" :LONG)
        (? "maxCpc" :LONG)
        (? "text" :STRING))
     (? "languageTargeting" (* "languages" :STRING))
     (? "geoTargeting" (* "countries" :STRING) (* "regions" :STRING)  
(* "metros" :STRING) (* "cities" :STRING))))

The syntax/sematics of which are defined as:

;; ELT = ( <multiplicity> "element-name" [ :primitive | ELT* ] )
;; where <multiplicity> is 1, ?, + or * and :primitive is a XSD  
primitive type keyword
;; all element types are resolved into primitives or sequences of sub  
elements
;; elements without contents are also possible

Three main functions are using the XSD template system:

- the code to document interpreted types, describe-xsd[-element]  
(also used by describe-wsdl-soap),
   that prints out the lisp style sexpr templates used for input/ 
output binding
- the code to bind an input binding sexpr into lxml, bind-element
- the code to resolve an output binding lxml into sexpr, resolve-element

The sexpr template for the above XSD template looks like this:

(getAllAdWordsCampaignsResponse
   (getAllAdWordsCampaignsReturn (
     ("id" :INT) 1
     ("name" :STRING) ?
     ("status" :STRING) ?
     ("startDate" :DATETIME) ?
     ("endDate" :DATETIME) ?
     ("dailyBudget" :LONG) ?
     ("optInSearchNetwork" :BOOLEAN) ?
     ("optInContentNetwork" :BOOLEAN) ?
     (campaignNegativeKeywords (
       ("id" :LONG) 1
       ("adGroupId" :INT) 1
       ("exemptionRequest" :STRING) ?
       ("criterionType" :STRING) ?
       ("language" :STRING) ?
       ("status" :STRING) ?
       ("negative" :BOOLEAN) ?
       ("destinationUrl" :STRING) ?
       ("type" :STRING) ?
       ("minCpc" :LONG) ?
       ("maxCpc" :LONG) ?
       ("text" :STRING) ? ) * )
     (languageTargeting
       ("languages" (:STRING) * )) ?
     (geoTargeting
       ("countries" (:STRING) * )
       ("regions" (:STRING) * )
       ("metros" (:STRING) * )
       ("cities" (:STRING) * )) ? ) + )) 1

An actual sexpr for the above sexpr template looks like this:

("getAllAdWordsCampaignsResponse"
(("getAllAdWordsCampaignsReturn"
    ("id"
     5631435
     "name"
     "Campaign #1"
     "status"
     "Active"
     "startDate"
     3335857874
     "endDate"
     3502857599
     "dailyBudget"
     1000000
     "optInSearchNetwork"
     T
     "optInContentNetwork"
     T
     "languageTargeting"(google::|email| "foo")
     (("languages" "en") ("languages" "nl"))
     "geoTargeting"
     (("countries" "BE") ("countries" "NL"))))))

At the moment, all test cases work, input and output is symmetrical,  
and the code in of better quality.

Hopefully independent testing will concur ;-)

Sven





From sven at beta9.be  Sun Oct  2 12:15:33 2005
From: sven at beta9.be (Sven Van Caekenberghe)
Date: Sun, 2 Oct 2005 14:15:33 +0200
Subject: [cl-soap-devel] API and Usability in CL-SOAP
In-Reply-To: <E1EKpc4-0007Rx-FF@imladris>
References: <E1EKpc4-0007Rx-FF@imladris>
Message-ID: <38D31EDE-B43C-4754-86D3-660A3E3770E5@beta9.be>


On 29 Sep 2005, at 06:01, Alain.Picard at memetrics.com wrote:

>
> Dear Sven,
>
> I've been playing with CL-SOAP, and thinking about what
> I'm going to have to layer on top of it to integrate it
> in my app.  I'm not sure I'm completely happy with what
> cl-soap currently provides, so let me know if you think
> my expectations are unrealistic.  :-)

> [...]

> I guess that that's the sort of deep integration I was _really_  
> hoping for.
>
> Lemme know your thougts.

Alain,

As described in our earlier (private) email conversations, I think that
(1) the current system is quite usable, especially now that it is  
finished somewhat more;
      it is now symmetrical in input vs output
(2) as described on http://common-lisp.net/project/cl-soap/google- 
adwords-api.html
      the usage scenario is now rather clean: do a describe-wsdl-soap  
on your service's wsdl,
      find the method that you want to call, study the input and  
output templates and
      write a rather straightforward and simple lisp function; the cl- 
soap framework will to all
      the required behind-the-scenes work automagically
(3) any stronger or higher level integration could be added on top of  
the current system,
      with a couple of macros
(4) I like the current representation and think that with a variant  
of getf and (setf getf) that uses string
       comparison you can get very far, without the need of  
converting to and from real clos objects
(5) you might want to have a look at how Franz did their SOAP addon;  
I did and found it
       to be more complicated than want we currently have (but  
potentially wider in scope)
(6) note that what you're suggesting is more than generating  
functions for each operation,
      each type needs to be represented as well, as are more  
complicated argument lists

> So
>  1) am I dreaming?

No, not really, but maybe you don't really need the stuff you are  
asking for.
Give this getf and (setf getf) scenario a change.

>  2) do you agree this would be good?

Although I wouldn't consider it necessary, it would be a useful  
addition,
and might appeal more to some people than the current scheme

>  3) do you consider this out of scope?

Not out of scope of the whole cl-soap project over a longer period;
somewhat out of scope of 'phase1' maybe

>  4) do you think we'd want to do this?

Eventually, yes - right now, no

But I am open for more discussions!

Sven

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2355 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cl-soap-devel/attachments/20051002/f5d8fde5/attachment.bin>

From sven at beta9.be  Sun Oct  2 18:01:45 2005
From: sven at beta9.be (Sven Van Caekenberghe)
Date: Sun, 2 Oct 2005 20:01:45 +0200
Subject: [cl-soap-devel] Announcing CL-SOAP
Message-ID: <DC4E4BAA-30BA-4368-9783-CDC2B96D81E9@beta9.be>

Last month I started a new open-source (LLGPL) project
on common-lisp.net called CL-SOAP, with as base URL:

http://common-lisp.net/project/cl-soap

CL-SOAP is a library that will ultimately implement
the full SOAP 1.1 spec, both the client and server sides,
using both HTTP and HTTPS as transports as well as
the WSDL 1.1 spec and the XML Schema Definition spec
on as many Common Lisp implementations as possible.
Interoperability with various other SOAP
implementations and applications will be possible.

Although no code has yet been released, the first
target has now been reached: CL-SOAP can act as
client to the Google AdWords API. This means the
basic SOAP framework including an HTTP/HTTPS client
works in document style, WSDL including XSD types
is parsed and used dynamically to make the actual calls.
To see this real-world code in action, goto

http://common-lisp.net/project/cl-soap/google-adwords-api.html

Furthermore, simple RPC style SOAP with or without WSDL
support also works (for automagic WSDL support,
parameter types must be simple though).

If you are interested, please check out the code, try
to make CL-SOAP work in your particular situation and
report back your experiences.

If you understand enough about the internals of SOAP,
WSDL and XSD, and have some free time, you are invited
to contribute actual code to CL-SOAP.

The following tasks are still open:
- test and (im)prove compatibility with other SOAP
   implementations and applications
- port to other Common Lisp implementations
- implement server side SOAP (document model)
- define WSDL in Lisp (and autogenerate it)
- implement more of WSDL and XSD.
- implement more of the SOAP RPC model and encoding,
   both for client and server

Sven Van Caekenberghe

http://homepage.mac.com/svc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2355 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cl-soap-devel/attachments/20051002/b6608ae0/attachment.bin>

From scaekenberghe at common-lisp.net  Mon Oct  3 12:35:54 2005
From: scaekenberghe at common-lisp.net (Sven Van Caekenberghe)
Date: Mon, 3 Oct 2005 14:35:54 +0200
Subject: [cl-soap-devel] Manipulating CL-SOAP sexpr
Message-ID: <15DD2F6F-C3B7-4095-89B6-6F13DC5B31BE@common-lisp.net>

CL-SOAP uses what I call 'sexpr' in input/output binding.
Basically these are nested plists with string keys.

I added some example functions to lxml.lisp to manipulate sexpr:

sexpr-get, (setf sexpr-getf), sexpr-select and sexpr-remove

This is a short listener interaction that shows their use:

;; sexpr-getf is much like CL's getf

CL-SOAP > (sexpr-getf '("x" 100 "y" 200) "x")
100

CL-SOAP > (sexpr-getf '("x" 100 "y" 200) "z")
NIL

CL-SOAP > (sexpr-getf '("x" 100 "y" 200) "y")
200

CL-SOAP > (setf foo '("x" 100 "y" 200))
("x" 100 "y" 200)

;; (setf sexpr-getf) is destructive, like (setf gethash) and friends

CL-SOAP > (setf (sexpr-getf foo "x") 1)
("x" 1 "y" 200)

CL-SOAP > (incf (sexpr-getf foo "x") 2)
("x" 3 "y" 200)

CL-SOAP > (decf (sexpr-getf foo "y") 2)
("x" 3 "y" 198)

;; (setf sexpr-getf) can be used to add elements (to the tail)

CL-SOAP > (setf (sexpr-getf foo "z") -1)
("x" 3 "y" 198 "z" -1)

;; sexpr-select is not destructive (much like SQL's select)

CL-SOAP > (sexpr-select foo '("x" "y"))
("x" 3 "y" 198)

CL-SOAP > (sexpr-select foo '("x" "z"))
("x" 3 "z" -1)

;; sexpr-remove is the inverse of select

CL-SOAP > (sexpr-remove foo '("x" "z"))
("y" 198)

HTH,

Sven



From scaekenberghe at common-lisp.net  Wed Oct  5 14:18:30 2005
From: scaekenberghe at common-lisp.net (Sven Van Caekenberghe)
Date: Wed, 5 Oct 2005 16:18:30 +0200
Subject: [cl-soap-devel] Re: cl-soap - the first 15 minutes of playing with
	it
In-Reply-To: <1128466130.12830.93.camel@localhost.localdomain>
References: <1128466130.12830.93.camel@localhost.localdomain>
Message-ID: <93D1BEA3-1624-4C89-AD1A-59F9C45F77CE@common-lisp.net>

Hi Kristian,

On 05 Oct 2005, at 00:48, Kristian Elof S?rensen wrote:

> Hi
>
> I just downloaded your cl-soap program and had a go. Here are the
> problems I encountered during the first minutes of playing with it.
>
>     Kristian
>
> ------------------------------------------------
>
> All code is on cmucl 19b on Linux on x86
>
> CL-SOAP> (lisp-implementation-version)
> "19b (19B)"
> CL-SOAP> (lisp-implementation-type)
> "CMU Common Lisp"

Thanks for taking the time to check out the CL-SOAP code!

> ;; OK - just to prove that the software is installed and works
> CL-SOAP> (describe-wsdl-soap (parse-wsdl-url
> "http://www.xmethods.net/sd/2001/CurrencyExchangeService.wsdl"))
> WSDL Document Definitions named CurrencyExchangeService
>   Service: CurrencyExchangeService
>     Port: CurrencyExchangePort
>     SOAP Address Location "http://services.xmethods.net:80/soap"
>     Binding: tns:CurrencyExchangeBinding SOAP style [rpc]
>       Operation: getRate
>         Input: getRateRequest
>           Part: country2 of type: xsd:string
>           Part: country1 of type: xsd:string
>         Output: getRateResponse
>           Part: Result of type: xsd:float
>
> ;; Interesting error message when the cause is that the elof.dk server
> returns a 404 error, see below
> CL-SOAP> (describe-wsdl-soap (parse-wsdl-url
> "http://elof.dk/does.not.exist.wsdl"))
> XML parser found <hr> not matched by </hr> but by <body> near stream
> position 308.
>    [Condition of type S-XML:XML-PARSER-ERROR]
>
> Restarts:
>   0: [ABORT] Abort handling SLIME request.
>   1: [ABORT] Return to Top-Level.
>
> Backtrace:
>   0: (S-XML::PARSE-XML-ELEMENT #<String-Input Stream>
> #<S-XML:XML-PARSER-STATE {59B8A8B5}>)
>   1: (S-XML::PARSE-XML-ELEMENT #<String-Input Stream>
> #<S-XML:XML-PARSER-STATE {59B8A8B5}>)
>   2: (S-XML::PARSE-XML-ELEMENT #<String-Input Stream>
> #<S-XML:XML-PARSER-STATE {59B8A8B5}>)
>   3: (S-XML::PARSE-XML-ELEMENT 2 #<String-Input Stream>
> #<S-XML:XML-PARSER-STATE {59B8A8B5}>)[:EXTERNAL]
>   4: (S-XML:START-PARSE-XML #<String-Input Stream>
> #<S-XML:XML-PARSER-STATE {59B8A8B5}>)
>   5: ((METHOD S-XML:PARSE-XML-DOM NIL (T #)) #<#1=unused-arg> #<#1#>
> #<String-Input Stream> #<#1#>)
>   6: (PARSE-WSDL #<String-Input Stream>)
>   7: (PARSE-WSDL-URL "http://elof.dk/does.not.exist.wsdl")
>   8: (EVAL (DESCRIBE-WSDL-SOAP (PARSE-WSDL-URL
> "http://elof.dk/does.not.exist.wsdl")))
>  --more--
>
> # tail -n 1 access_log
> www.elof.dk 10.10.10.4 - - [05/Oct/2005:00:20:38 +0200]
> "GET /does.not.exist.wsdl HTTP/1.1" 404 317 "-" "HTTP Client CMU  
> Common
> Lisp 19b (19B)"

I added an optional test that enforces the response code for do-http- 
get on the url passed to parse-wsdl-url and parse-xsd-url to be 200.  
Incidentally, if the error was presented in proper XHTML, the XML  
parse would have succeeded, but it would report missing a  
<definitions> tags...

> #|
>  On the webpage http://common-lisp.net/project/cl-soap/
>  The line
>  (asd:oos 'asdf:load-op :cl-soap)
>  is missing an #\f in asdf at the start.
>  People are bound to copy and paste the line like I did ,-)
> |#

Thanks for noticing and reporting this typo.

> ;;  The first example from your webpage
> (defun xmethods-get-quote (symbol)
>   "Calling
> http://services.xmethods.net/soap/urn:xmethods-delayed-quotes.wsdl"
>   (let ((ns "urn:xmethods-delayed-quotes"))
>     (s-xml:register-namespace ns "ns1" :ns1)
>     (let* ((xmethods (make-soap-end-point
> "http://64.124.140.30:9090/soap"))
>            (result (soap-call xmethods
>                               '()
>                               `((ns1::|getQuote|
>                                  soapenv:|encodingStyle| ,
> +soap-enc-ns-uri+
>                                  :|xmlns:ns1| ,ns)
>                                 ((:|symbol| xsi::|type| "xsd:string")
>                                  ,symbol))
>                               :soap-action
> "urn:xmethods-delayed-quotes#getQuote")))
>       (if (eql (lxml-get-tag result) 'ns1::|getQuoteResponse|)
>           (let ((contents (lxml-find-tag :|Result| (rest result))))
>             (if contents
>                 (coerce (read-from-string (lxml-get-contents  
> contents))
> 'float)
>               (error "Expected a <Result> element")))
>         (error "Expected a <getQuoteResponse> element")))))
>
> Reader error at 403 on #<String-Input Stream>:
> package "NS1" not found
>    [Condition of type LISP::READER-PACKAGE-ERROR]
>
> Restarts:
>   0: [ABORT] Abort handling SLIME request.
>   1: [ABORT] Return to Top-Level.
>
> Backtrace: [...]

Doing this in the LispWorks IDE gives you the option (restart) of  
actually creating the missing package.
The source code file test/test-basic.lisp where this code snippet  
came from *does* contain the (make-package :ns1) statement. I added a  
remark to the HTML page index.html noticing that the code assumes  
there exists a package named :ns1.

Sven




From scaekenberghe at common-lisp.net  Thu Oct  6 12:02:54 2005
From: scaekenberghe at common-lisp.net (Sven Van Caekenberghe)
Date: Thu, 6 Oct 2005 14:02:54 +0200
Subject: [cl-soap-devel] ScheduleReportJob [was Re: CL-SOAP Progress]
In-Reply-To: <17220.24346.77153.997434@memetrics.com>
References: <17211.16532.610506.250236@memetrics.com>
	<1492003E-F5EE-4B89-ABD1-FD730C9E35B7@beta9.be>
	<17212.31305.611909.517247@memetrics.com>
	<7645A5FA-8127-40C4-B30A-A0C73ECCC690@beta9.be>
	<17213.5511.304491.888683@memetrics.com>
	<CA308608-9072-4531-BF41-73F240B60A67@beta9.be>
	<17219.11999.394717.586476@memetrics.com>
	<17219.26150.339554.635847@memetrics.com>
	<FA69D865-E376-402F-B565-C7D6D5BDB072@beta9.be>
	<17220.24346.77153.997434@memetrics.com>
Message-ID: <E0ABB6A3-CD88-4B76-85A0-BAC94B001409@common-lisp.net>


On 06 Oct 2005, at 01:17, Alain.Picard at memetrics.com wrote:

> Sven Van Caekenberghe writes:
>
>> It is very interesting that you are trying to use the  
>> ReportService API...
>
> OK, I think I've found what I need to do to create a report job,
> but I don't know how to do it with CL-SOAP.
>
> Consider this function:
>
> (DEFUN SCHEDULE-REPORT-JOB (&KEY JOB)
>   (WSDL-SOAP-CALL
>    (WSDL-CACHE-GET "https://adwords.google.com/api/adwords/v2/ 
> ReportService?wsdl")
>    "scheduleReportJob"
>    :INPUT
>    (LIST "scheduleReportJob"
>      (LIST "job" JOB))
>    :HEADERS
>    (MAKE-GOOGLE-HEADERS)))
>
> Now, I found people having problems, with the same Java exception
> raised (missing constructor) as we have.  Their solution was to
> send:
>
>     <scheduleReportJob>
>        <job xsi:type="CustomReportJob">
>            ....
>
> Instead of just <job>.
>
> (I suspect this is in fact a bug in their implementation of the
> API, but don't know enough about this stuff to be 100% sure).
>
> Any ideas how to get CL-SOAP to issue something like this?
> I tried
>
> (DEFUN SCHEDULE-REPORT-JOB (&KEY JOB)
>   (WSDL-SOAP-CALL
>    (WSDL-CACHE-GET "https://adwords.google.com/api/adwords/v2/ 
> ReportService?wsdl")
>    "scheduleReportJob"
>    :INPUT
>    (LIST "scheduleReportJob"
>      (LIST "job  xsi:type=\"UrlReportJob\" " JOB))
>    :HEADERS
>    (MAKE-GOOGLE-HEADERS)))
>
> But that fails because it cannot find a binding for job xsi=....
>
> We may need some extra syntax in there to dissociate the binding
> element from it's args.  (Or maybe it's already in there and I
> didn't find it).
>
> Help?

OK, here is the deal:

ReportJob is like an abstract type with 4 concrete subtypes: [KeyWord| 
AdText|Url|Custom]ReportJob.
As such this case was implemented (members are simply inherited from  
super to sub types).
However, when binding input the operation signature only mentions  
(and knows of) the abstract type.
There was no provision to specify a concrete subtype.

I managed to add a special case for this purpose without messing up  
the code too much.
The following function (from test/test-xsd.lisp) show how to schedule  
a report job:

(defun test-3 ()
   (let* ((schema (get-xml-schema-definition
                   (wsdl-cache-get "https://adwords.google.com:443/ 
api/adwords/v2/ReportService?wsdl")))
          (template (generate-xsd-template "scheduleReportJob" schema))
          (binding `("scheduleReportJob"
                     ("job"
                      (xsi:|type| "UrlReportJob"
                       "name" "test123"
                       "startDate" ,(ut)
                       "endDate" ,(ut)
                       "clientAccounts" (100 200)
                       "adWordsType" "SearchOnly"
                       "campaigns" (101 201))))))
     (bind-xsd-template template
                        binding
                        schema
                        *google-adwords-ns*)))

The convention is that a special purpose member called xsi:|type|  
whose value is the concrete subtype being used can be added where  
needed (incidentally, XSI stands for XML Schema Instance). The above  
code works as follows:

CL-SOAP 313 > (pprint (test-3))

((GOOGLE::|scheduleReportJob|
   ((GOOGLE::|job| XSI:|type| "UrlReportJob")
    (GOOGLE::|name| "test123")
    (GOOGLE::|startDate| "2005-10-06T00:00:00.000-01:00")
    (GOOGLE::|endDate| "2005-10-06T00:00:00.000-01:00")
    (GOOGLE::|clientAccounts| "100")
    (GOOGLE::|clientAccounts| "200")
    (GOOGLE::|adWordsType| "SearchOnly")
    (GOOGLE::|campaigns| "101")
    (GOOGLE::|campaigns| "201"))))

CL-SOAP 314 > (s-xml:print-xml (first (test-3)) :stream *standard- 
output* :pretty t)

<google:scheduleReportJob>
   <google:job xsi:type="UrlReportJob">
     <google:name>test123</google:name>
     <google:startDate>2005-10-06T00:00:00.000-01:00</google:startDate>
     <google:endDate>2005-10-06T00:00:00.000-01:00</google:endDate>
     <google:clientAccounts>100</google:clientAccounts>
     <google:clientAccounts>200</google:clientAccounts>
     <google:adWordsType>SearchOnly</google:adWordsType>
     <google:campaigns>101</google:campaigns>
     <google:campaigns>201</google:campaigns>
   </google:job>
</google:scheduleReportJob>

Hopefully, this code will work in the actual call ;-)

Sven






From scaekenberghe at common-lisp.net  Sun Oct  9 20:13:32 2005
From: scaekenberghe at common-lisp.net (Sven Van Caekenberghe)
Date: Sun, 9 Oct 2005 22:13:32 +0200
Subject: [cl-soap-devel] Re: Announcing CL-SOAP
In-Reply-To: <8757cb490510091148r6a1e501bs7c6b27107e1cb27e@mail.gmail.com>
References: <DC4E4BAA-30BA-4368-9783-CDC2B96D81E9@beta9.be>
	<8757cb490510081834t6fa1317fuf54519ad9c28121e@mail.gmail.com>
	<5123E8C1-D7E8-49CD-AE76-786D5E9C0D46@beta9.be>
	<8757cb490510091148r6a1e501bs7c6b27107e1cb27e@mail.gmail.com>
Message-ID: <4F4D416F-A2F4-4102-81D6-6AA434AB9275@common-lisp.net>


On 09 Oct 2005, at 20:48, Bill Clementson wrote:

> Hi Sven,
>
> Deleting all of the fasl files and doing a cvs update fixed the
> problem - thanks!

That's a relief.

> Now, the basic examples seem to work fine (with the exception of the
> currency conversion example which appears to be a problem at the
> service end and not with your code).

Maybe, or maybe you used the wrong arguments:

CL-SOAP 8 > (xmethods-get-rate "us" "japan")
;; SOAP CALL sending:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/ 
envelope/" xmlns:xsd="http://www.w3.org/1999/XMLSchema"  
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance">
   <soapenv:Body>
     <ns1:getRate soapenv:encodingStyle="http://schemas.xmlsoap.org/ 
soap/encoding/" xmlns:ns1="urn:xmethods-CurrencyExchange">
       <country1 xsi:type="xsd:string">us</country1>
       <country2 xsi:type="xsd:string">japan</country2>
     </ns1:getRate>
   </soapenv:Body>
</soapenv:Envelope>
;; SOAP CALL receiving: <?xml version='1.0' encoding='UTF-8'?>
<soap:Envelope xmlns:soap='http://schemas.xmlsoap.org/soap/envelope/'  
xmlns:xsi='http://www.w3.org/1999/XMLSchema-instance'  
xmlns:xsd='http://www.w3.org/1999/XMLSchema' xmlns:soapenc='http:// 
schemas.xmlsoap.org/soap/encoding/' soap:encodingStyle='http:// 
schemas.xmlsoap.org/soap/encoding/'><soap:Body><n:getRateResponse  
xmlns:n='urn:xmethods-CurrencyExchange'><Result  
xsi:type='xsd:float'>113.79</Result></n:getRateResponse></soap:Body></ 
soap:Envelope>
113.79

> Most of the wsdl examples have a comment in them that says "doesn't
> work...". Is this a problem with the xmethod's service's wsdl or is it
> because there is wsdl functionality that you still need to implement
> before the service's description can be retrieved correctly?

Both.

The marked ones also have an explanation of why (I think) they do not  
work.
But it is also true that I wouldn't expect everything to work with  
the current state of the implementation.

As you probably read between the lines, CL-SOAP was started and  
brought to 'phase 1' in response to a request by Alain Picard from  
Memetrics - with financial support by Memetrics and Beta Nine. The  
goal of phase 1 was basically to be able to talk to the Google  
AdWords API. This required HTTPS client support, the SOAP framework,  
document style calls (as opposed to the more common rpc style), WSDL  
support and non-trivial XSD typing. All in all, more than this  
minimum is now working.

However, to move things forward, help is needed from people with  
knowledge of how SOAP works and who are willing to put some time in  
extending/improving CL-SOAP - in my opinion this can only be done by  
pursuing concrete goals like talking to this or that public SOAP API.  
WSDL and especially XSD are way to complex and broad to implement  
completely - to only solution is to be pragmatic.

> I am subscribing to the CL-SOAP mailing list and will send my future
> comments/questions to the list.

OK - I took the liberty of cc'ing this reply to the list.

> I also tried out cl-soap with OpenMCL (which I normally prefer to use
> over LW) and the same examples worked with OpenMCL.

That is good news.

> I'll let you know if I encounter any other issues.

Please do.

Sven




From billclem at gmail.com  Sun Oct  9 20:30:33 2005
From: billclem at gmail.com (Bill Clementson)
Date: Sun, 9 Oct 2005 13:30:33 -0700
Subject: [cl-soap-devel] Re: Announcing CL-SOAP
In-Reply-To: <4F4D416F-A2F4-4102-81D6-6AA434AB9275@common-lisp.net>
References: <DC4E4BAA-30BA-4368-9783-CDC2B96D81E9@beta9.be>
	<8757cb490510081834t6fa1317fuf54519ad9c28121e@mail.gmail.com>
	<5123E8C1-D7E8-49CD-AE76-786D5E9C0D46@beta9.be>
	<8757cb490510091148r6a1e501bs7c6b27107e1cb27e@mail.gmail.com>
	<4F4D416F-A2F4-4102-81D6-6AA434AB9275@common-lisp.net>
Message-ID: <8757cb490510091330u7d109eaey293c8e2ab2a73c94@mail.gmail.com>

On 10/9/05, Sven Van Caekenberghe <scaekenberghe at common-lisp.net> wrote:
>
> On 09 Oct 2005, at 20:48, Bill Clementson wrote:
> > Now, the basic examples seem to work fine (with the exception of the
> > currency conversion example which appears to be a problem at the
> > service end and not with your code).
>
> Maybe, or maybe you used the wrong arguments:

Ahh, that was it! I thought I was supposed to pass in currency codes
and not country names (e.g. - I was sending in "USD", "CAD", "GBP"
instead of "US", "CANADA", "ENGLAND"). mea culpa.

> > Most of the wsdl examples have a comment in them that says "doesn't
> > work...". Is this a problem with the xmethod's service's wsdl or is it
> > because there is wsdl functionality that you still need to implement
> > before the service's description can be retrieved correctly?
>
> Both.
>
> The marked ones also have an explanation of why (I think) they do not
> work.
> But it is also true that I wouldn't expect everything to work with
> the current state of the implementation.
>
> As you probably read between the lines, CL-SOAP was started and
> brought to 'phase 1' in response to a request by Alain Picard from
> Memetrics - with financial support by Memetrics and Beta Nine. The
> goal of phase 1 was basically to be able to talk to the Google
> AdWords API. This required HTTPS client support, the SOAP framework,
> document style calls (as opposed to the more common rpc style), WSDL
> support and non-trivial XSD typing. All in all, more than this
> minimum is now working.

Actually, for a "Phase 1" deliverable, quite a lot of stuff is
actually working!

> However, to move things forward, help is needed from people with
> knowledge of how SOAP works and who are willing to put some time in
> extending/improving CL-SOAP - in my opinion this can only be done by
> pursuing concrete goals like talking to this or that public SOAP API.
> WSDL and especially XSD are way to complex and broad to implement
> completely - to only solution is to be pragmatic.
>
> > I am subscribing to the CL-SOAP mailing list and will send my future
> > comments/questions to the list.
>
> OK - I took the liberty of cc'ing this reply to the list.

That's fine - I'll also cc the list with this reply and any future comments.

Cheers,
Bill