Gordon and Ingo both seem amused by Paul's use of the ISO model to discredit SOAP.  Robert Leftwich finds the evolved or co-opted use of the term REST to be confusing or misleading.

I actually have two incomplete essays on the topic that I'm shelving as it seems that this is a topic is beyond rational discourse at the present time. [Sam Ruby]

I'm more than willing to concede that REST has some very good points; for example, GET is extremely handy and is probably underutilized in the SOAP world.  I agree that URIs are also incredibly powerful and that SOAP could or should leverage them more.  And I recognize the potential to repeat past mistakes with distributed RPC systems.

This isn't just theory, I did some work on putting a SOAP interface on a mapping vendor's RESTish interface (though I didn't know the term then, and their interface was all POST)  last summer.  I found that in my typical use case for retrieving maps, I wanted a GET interface; in fact, SOAP just got in the way sometimes.  This isn't a religion for me, I'm just trying to get things done.  What I can't understand is why SOAP has to lose in order for REST to win.

Nevertheless, I think judging SOAP as a bad thing because it doesn't fit a seven layer network model is an interesting way of proving one's point ;-) [Ingo Rammer's DotNetCentric]

Yeah, that's what I thought when I hit that part of Paul's post.  I'd learned in the networking class I took in college that TCP/IP didn't fit into the OSI model, that the OSI model was a theory that didn't fit too many real world applications.  Funny that Paul's trying to fit HTTP back into that model when 9 years ago, my professor was telling me it didn't fit!

I've made more progress on the SoapExtensionReflector, but I've been stalled for the last week or so because I'm supporting a customer on our (that is, Galileo's) rollout of our web services. 

What I'm trying to do is to is to define an attribute that I can apply like XmlAnyType.  If you're asking why I'd want to do this, it's because we're writing some message oriented services which pass documents around.  We would like the schema for the document to be published in the WSDL so that the full contract is available in the WSDL.  Here's the definition I have so far.  One thought I'm having is that I could just subclass XmlAnyType and add the Type & SchemaLocation properties, but I'm a little unsure if that's appropriate.

[AttributeUsage(AttributeTargets.Field |
  AttributeTargets.Parameter |
  AttributeTargets.Property |
  AttributeTargets.ReturnValue, Inherited= false, AllowMultiple=false)]
public class XmlImportedElementAttribute : Attribute
{
 public XmlImportedElementAttribute()
 {
 }
 public String Type
 {
  get
  {
   return typeName;
  }
  set
  {
   typeName = value;
  }
 }
 public String SchemaLocation
 {
  get
  {
   return schema;
  }
  set
  {
   schema = value;
  }
 }
 public String Namespace
 {
  get
  {
   return ns;
  }
  set
  {
   ns = value;
  }
 }
 private String schema;
 private String ns;
 private String typeName;
}

So the usage of this would be much like XmlAnyElement, except that you'd provide a location to load the schema from (this will appear in a wsdl:import element in your wsdl) and the name of the XSD type that you want to substitute for the xs:any element that XmlAnyElement would put in the WSDL. 

Right now, the stumbling block is that I don't have a good understanding of how message parts are generated.  There seems to be a default part called "parameters" on every message, but I'm not sure how or if other parts are generated.  Clearly, in the default case, the path from a message to a schema element is trivial, but I want to make sure I have the wierd cases covered too.

[Joe's Aggie tool is] neat, but to be fair, that 23k download requires the .NET runtime, a 21Mb download if you don't have it. [Simon Fell]

I wonder if people have stopped saying "To be fair, you need to download the Java runtime, which is blahblah if you don't have it", and when. Will it be an indication of .NET's success when Simon won't feel the need to tell people they need the runtime? :) [The .NET Guy]

It's not really an apples to apples comparison, the JRE is less than half that, ~9MB.  Maybe you get more in the .NET runtime, but I think the point remains.  21 MB is still a big chunk for a little application.  I agree that the runtime download is a bit of a red herring, but maybe MS could alleviate some of that with a .NET runtime edition.  My guess is that the .NET runtime also installs server side components, which certainly aren't necessary for the client download situation.

FWIW, I've used Aggie a bit at work.  I don't like the default display much, but I can always change it when it starts to bug me enough.  I tried AmphetaDesk & Feedreader, one wouldn't save my subscriptions and the on the other, I couldn't figure out a proxy server setting.  I'm not a very sophisticated RSS consumer, but for me, Aggie just works, and that's good enough for now.