@ClemensVasters: Right, but my point is you have to have a strategy that deals with change.
The best way to think about it is that the schema is a DSL which can be used to automate code functions like validation, serialization, GUI display, reports etc.. That DSL needs to be able to cope with minor and major changes, and expressive enough to deal with complex conditional optional structures.
This approach shouldn't be applied everywhere (if the size of the dataset is trivial). And, if the DSL isn't rich enough or the approach has failed before the solution is to fix the DSL rather than just resort to a non-machine readable schema document. If you go typeless you've removed the ability to automate a large part of your system.
I don't really think you can generalize on this. For simple interactions like the examples given, schema and a shared type is overkill. But in a large complex transactional system, with 100 or 1000s of fields it simply doesn't make sense to avoid schema.
If there's no machine readable schema then each developer has to write their own serializer and deserialize code. A process reading a complex message of 400 or more fields in a structured document would have verify the presence of each field before they use it. This can lead to monotamaus, buggy code.
It's far easier to automate the task of verifying the message against one of the valid schemas. Providing for basic for rules for non-break minor changes is a must. The validation code can be generated - and once you have a valid message you can deserialize it so that you can programmatically access the contents.
Resorting to manual message validation and serialization as a way of solving the issue of tight coupling is really solving the sympton rather than the cause. The real issue is to have a versioning strategy with a flexible automated code generation system that is designed for loosely coupled providers and consumers.
A good practical example of this is Google Protocol Buffers extension mechanism. With ProtoBufs you can partially deserialize from a code generated class and load an extension schema in dynamically at runtime to access additional data. Much like C#'s hybrid static and dynamic typing.
As for the static vs dynamic typing - surely a langauge that allows for both is the best.
This looks great. But the problem is that it doesn't quite give you what the Web Essentials extension did before it. The CSS page inspector looks great, but changes aren't reflected automatically - you need to refresh. This is fine for most sites, but for Singla Page Applications, when on a dialog where the page's state isn't reflected in the URL it's a pain. You would need to fire up the dialog again. Why not support dynamic CSS changes?