intertwingly

Sam,
  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.

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.

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:

http://bitworking.org/archival/comment_soap_transcript.txt

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...

<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.

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

http://bitworking.org/archival/comment_soap_transcript2.txt

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.

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

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.

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...

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.

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).

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

http://www.w3.org/TR/soap12-part1/#soapbodyel

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

http://www.w3.org/TR/2001/WD-soap12-20010709/#_Toc478383503

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

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...