deem  (dēm)
v. deemed, deem·ing, deems
v. tr.
  1. To have as an opinion; judge: deemed it was time for a change.
  2. To regard as; consider: deemed the results unsatisfactory.
n.
  1. A Weblog: Mike Deem's Weblog was last updated 5/13/2002; 10:31:30 AM.
May 2002
Sun Mon Tue Wed Thu Fri Sat
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
Apr   Jun

  


Thursday, May 09, 2002
10:39:38 AM    Comment ()  

I think I need to say this in an unambiguous way as possible:

  • I think that every SOAP and WSDL implementation should support every feature of the SOAP and WSDL specifications. That is the only way to insure true universal interop.
     
  • SOAP and WSDL are complex specifications with lots of surface area (including all of XML Schema) with lots of special edge cases where they bump up against each other and other specifications. It is practically impossible for every implementation to implement every feature of the SOAP and WSDL specifications. It certainly can't happen "all at once," but only though a continual process.
     
  • The SOAP 1.1 and WSDL 1.1 specifications are essentially drafts. They had not received the careful consideration from a diverse working group that is necessary to insure that they are complete and appropriate. In the process of implementing them, a number of instances of where they are incomplete or inappropriate may be encountered. At these points, a developer is forced to make a guess as to what the intent of the specifications may be.
     
  • We (meaning the SOAP community as embodied on soapbuilders) have done a damn fine job working around and within these specifications to deliver an amazingly interoperable cross platform messaging infrastructure. It is an accomplishment that ranks very high on the all time list of truly wonderful things that have happened with computers. We should be very proud of this.
 
12:26:53 AM    Comment ()  

[Simon Fell] Keith & Mike both seem happy to subset SOAP and WSDL. Wave bye-bye to the chance that SOAP interop means anything more than interops with MSFT. Where are all the MSFT guys who were up in arms 12-18 months ago about subsets?

Oh come on!

Choosing not to support a given feature of a specification is very different from publishing a subset of a specification and implementing only that. The first case merely reflects the the limitations of a platform, the specific needs of a given application domain, or the scarcity of resources available for implementation. The latter is more akin to trying to take control of a technology from a standards body and forcing other vendors to come along.

Which category do you honestly think Microsoft's SOAP and WSDL implementations fall into? What about the other vendors that do not implement everything in SOAP and WSDL? Is there any reason Microsoft should be held to a different standard then these other vendors?

My point here, which you seem to have completely missed (which must be my fault), was that vendors necessarily prioritize the features they think are important to their customers. They get the important ones done and never quite find the time or need to do the others. If a vendor gets feedback on missing features from their customers, the vendor changes their priorities and gets those features done. If every vendor ends up getting the same set of features done, it most likely means that those features are the core of a technology.

As the specifications for that technology evolve, they should reflect this reality by specifically identifying the less desirable features as being adjuncts or optional. If the standards don't change in this way, then you really do end up with a situation where interoperability is defined by the vendor with the largest market share. That is what I do not want to happen!

 


© Copyright 2002 Mike Deem.



Click here to visit the Radio UserLand website.

Click to see the XML version of this web page.

med@myself.com