intertwingly

Well, it’s an onion, isn’t it? At first, he had five problems. O/X mapping, WS-Addressing, WSRF, XML, HTTP1.1. He’ll be down to two.

I don’t accept the parsing pain of XML and markup in general at the protocol level. He can use JSON (or maybe JSON2, so he has date literals).

Then, he has to replace HTTP’s MIME syntax. That last one should be interesting.

Ronald: pseudonyms are for trolls.  Stop that.

Onion, indeed.  But if you think that there are only 5 layers, you didn’t read the links I provided carefully enough.  For example, characters and URIs each present unique problems.  I’ve written on the issues of dates and decimal types - both common in so-called e-commerce applications.

JSON definitely fills a certain niche nicely, but not every problem is a nail.  Google’s search is an application that presents a form in what amounts to a relaxed XML grammar, and then accepts input in the form of URI encoded parameters, and then responds again with a relaxed XML grammar.

O/X, URI encoded parameters, and JSON are all forms of inside-out programming, quite useful in AJAX applications, where the client application itself is provided by the server; but are not generally suitable for Small Pieces, Loosely Joined types of approaches.

JSON is probably better for inside-out programming than XML, but I don’t think that rules it out for Small Pieces, Loosely Joined types of approaches. A validator and a grammar are what’s needed to make the leap. JSON is my sawzall.

The extract method is basically done. I’m sure it could be improved a bit more, but it seems to be fairly effective. I added a few extra features beyond the original URI class’s capabilities, such as supplying a base uri to resolve...

The extract method is basically done. I’m sure it could be improved a bit more, but it seems to be fairly effective. I added a few extra features beyond the original URI class’s capabilities, such as supplying a base uri to resolve...