It’s just data

CommentAPI, now with SOAP?

Joe Gregorio: would it be more palatable if the CommentAPI supported an optional SOAP envelope?

Just be aware that anybody who sends you a SOAP envelope is likely to expect you to respond in kind.  To help further discussion, here is a Cheetah template for SOAP faults.  Invoke it from within any except: block in Python.

  Thanks for the Cheetah template. I have updated my commenting system to now accept SOAP envelopes, and to produce proper error messages using your template.

Posted by joe at

Joe: Cool - that's error messages.  The one remaining question is whether or not your commenting system will 'respond in kind' upon receipt of message with optional soap headers that can be successfully processed.

If you can describe what a successful response looks like, I can produce a WSDL for the message exchange.

Posted by Sam Ruby at

Can you give me a little more detail on what you mean by 'respond in kind'?

For now, if the request is successful the result is an HTML message. A soapfault is generated when things go wrong. Here is the transcript from my testing:

Posted by joe at

CommentAPI now with experimental SOAP support

I am experimenting with adding support for an optional SOAP envelope on the CommentAPI. I haven't updated the specification for the CommentAPI, waiting instead for feedback from y'all. Thanks to Sam my script will produce a correctly formatted SOAP...

Excerpt from BitWorking at

<Respond in kind> := <well formed XML inside a SOAP body inside a SOAP envelope>.

For more details, see A Gentle Introduction To SOAP.

You can meet the letter of this requirement, but not the spirit, by simply adding an envelope and body around your HTML.

To meet the spirit of this requirements, separate the presentation from the data in the response.  Pure, clean, simple XML.  Wrapped in an envelope and body.

Posted by Sam Ruby at

Done. Here is a transcript of my testing which shows the responses:

Posted by joe at

Joe: way cool!

Now for one minor tweak to allow for the maximum interoperabilty for the widest amount of toolkits: make the element which is immediately nested within the <soap:Body> (i.e., <item>) have a namespace other than "".  This is for both requests and responses.

My personal recommendation would be that all nested elements be placed in such a namespace.

Posted by Sam Ruby at

But then it wouldn't be an RSS 2.0 'item' fragment.

Posted by joe at

Joe, I know, I know.

I'm sure you remember when I tried rather hard to get RSS to adopt a namespace, but I encountered some, um, er... resistance.

Both the RSS validator and the ultraliberal RSS parser accept both namespace qualified and unqualified elements. 

The question I'm putting on the table is whether or not  it would be possible for RESTLog to accept either unqualified or elements qualified in a specific namespace of your choosing.

Posted by Sam Ruby at

Is it possible? Of course, it's just code after all. On the otherhand I don't think it's a good idea. If CommentAPI accepts  'item's in the nil namespace and in some other namespace I see that as sowing seeds of confusion. If I implemented your idea, here are the questions I would have to answer:

1. Do I have to use the namespace?
2. Do I have to use the namespace if it isn't wrapped in a SOAP envelope?
3. Will the 'item' returned from a successful SOAP call be in the same namespace as the item that was passed in?
4. Will the 'item' returned from a successful SOAP call not be in a namespace if the item that was passed in wasn't in a namespace?
5. Will the RESTLog interface also take 'item's in the same namespace?
6. Will the RSS feed produced by RESTLog  have it's items in the same namespace?

And I could go on.

I don't think I'll do it, but I am always open to persuasive arguments...

Posted by joe at

I'd prefer consistency.  Either we require namespace qualification or we don't.  The SOAP spec doesn't require body elements to be qualified so if a particular SOAP package requires namespaces, then it's not a particularly useful SOAP package ;-) 

Seriously, I'd prefer limiting the options.

Posted by James Snell at

Til you get to SOAP 1.2, which does require the child of body to be NS qualified (or at least did, last time i looked at the spec).

Posted by Simon Fell at

I may be misreading it only looks like a 'should' and not a 'must':

Looks like it's been upgraded from a 'may':

Posted by joe at

Joe pushes back

Joe Gregorio: I don't think I'll do it, but I am always open to persuasive arguments... There's nothing more persuasive than seeing the problem with your own eyes.  Since you seem to like C# on the client... wsdl CommentAPI.wsdl csc ...

Pingback from Sam Ruby: Joe pushes back


Pushing Back

Sam's example isn't very persuasive for why a namespace should to be added to the 'item' element in the CommenAPI. Here is my own eerily similar example of why the namespace isn't needed and the SOAP envelope is optional. xsd CommentAPI.xsd /c csc...

Excerpt from BitWorking at

Add your comment