What is needed is a simple, extensible mechanism for exchanging XML documents and metadata about the content, source, and destination of the XML document. This is the core of XML messaging, this is how to unify SOAP and REST, and this is what should've happened in the first place. [codaland]

There's this tension between the object and XML schools of thought that runs pretty deep. The group that I work with is pretty firmly in the XML camp, but this is a difficult point to communicate, even within the company. There's still a strong belief that everything must be serialized into an object, so when we tell people that we're just passing XML Elements, and they should leave the result in a DOM, we get quite a bit of resistance. This has been a running argument for a few years, way before we started doing SOAP. I view SOAP as a way to move forward on that issue; we use a DOM, however our clients want to use it is up to them.

...a service can choose to expose a SOAP endpoint that only performs a query as an HTTP GET. The body entity returned would be a SOAP packet.

But to me this is a step back and constrains me to a point-to-point system. With all these specs (WS-Security in particular) coming out that depend on SOAP headers to convey credentials as well as assertions for federated security, an HTTP GET based system is going to be outside the norm and won't be able to use all the new goo. So why bother? [Justin Rudd]

Maybe this is already being considered, or maybe it's impossible, but can't all the WS-* stuff be mapped into HTTP headers? I suppose that the advantage of having this stuff in the envelope means that the envelope is truly transport independent - routing now becomes simply a matter of some address translation, with no mucking with the message. But the thing is that in a message based system, the operations suitable for GET have pretty simple bodies; partly forced by the limits on URL length enforced by the HTTP implementations out there. The natural way to do the out of band stuff in HTTP is in the headers, but now routing is more complex. This also goes against the current direction for SOAPAction, the one SOAP HTTP header. But now that I think about it, that direction seems wrong. There's cases where a GET binding makes sense, but not if you have to encode the SOAP headers into the URL.

Design Patterns that aren't. I really like this. Rather than blindly following the GoF, this guy looks at the source of it all. [The Wagner Blog]

The author argues that design patterns as we currently know them are the result of having bad languages (C++, Java) rather than actually solving architectural problems. We can see that C# has addressed some of this, for example, the incorporation of Observer via inclusion of delegates in the language. But C# is still not a high level language, as Patrick Logan, among others, has said repeatedly. Thus, GoF solves the problem by "turn the programmer into a fancy macro processor".

The problem Alexander is trying to solve is: How can you distribute responsibility for design through all levels of a large hierarchy, while still maintaining consistency and harmony of overall design?

So my question is, what would Design Patterns have looked like if it was written for, say, Scheme programmers?