"An XML web service is, to a first approximation, a wide-area RPC service in which requests and responses are encoded in XML as SOAP envelopes, and transported over HTTP.".
This extract from this piece is so not what I think an XML web service is.
If that is what it is then why not just badge any one of a zillion RPC centric distributed technologies and stick a layer of pointy brackets on top. Why re-invent it? Whats the point?
I think Web Services technology *does* need to be invented because its benefits come from it *not* being a wide-area RPC mechanism. Web servicies are not, as far as I'm concerned, distributed objects. If they are, its all a bit of a waste of time and money reinventing it isn't it?

posted by Sean 1:36 AM

[Link] . . .

[via Webmink]. A graphic illustration of the problem.

posted by Sean 12:56 AM

[Link] . . .

Campaign for a "None of the Above" option on electronic ballots in Ireland.
Personally, I think a "MU" option would be an excellent addition.

posted by Sean 1:56 PM

[Link] . . .

bloggers who will be blogging next weeks XML USA conference.

posted by Sean 8:08 AM

[Link] . . .

About this time last year I was noodling the pros/cons of a machine readable anti-linking mechanism.
Today I found this a really simple suggestion for how to do it with services like tinyurl. Isn't the Web's predisposition towards intermediation a great and wonderful thing?

posted by Sean 4:59 AM

[Link] . . .

A big Amen Brother to this piece by Werner Vogels.

posted by Sean 6:08 AM

[Link] . . .

The Shuttleworth Foundation has some Python projects it would like to see done and some money to make it happen in 2004.

posted by Sean 3:11 AM

[Link] . . .

A good article, and a well put conclusion:

"Our interest in Python developed from a prototyping standpoint, but we quickly adopted it as the language of choice for our management interface as well as for ad-hoc prototyping of future concepts. Numerous developers have come up to speed with Python quickly, and they have expressed pleasant surprise at the simplicity of the language and how quickly they are able to fulfill functional requirements with it. Moreover, Python's robust string and file handling (as well as its built-in types) make it the language of choice for our user interface. We're quite excited about the potential that Python has given us.

In the future, Python will be looked upon favorably by both the development staff and the company at large, because it has allowed us to respond to customer requests in a fast-paced, rapid development environment. The built-in types, lack of compilation, interactive interpreter and usability of Python have made it the language of choice of many and have raised the bar of excellence when evaluating other languages."

posted by Sean 6:31 AM

[Link] . . .

Its been over a year now and still now sign of 'googlechopped' being googlechopped

posted by Sean 12:34 PM

[Link] . . .

Works great in the small, less great in the large. What we need is a grand unifying theory of how applications can interact with other applications. God, as far as I'm concerned, does not play DCE with the universe:-)

posted by Sean 5:47 AM

[Link] . . .

Before getting too excited about the potential of desktop applications that connect to the web but run outside the browser, it is worth considering what might be lost. In particular, the sheer simplicity of apportioning blame, in the event of a malfunction. In a Dilbertian way, this is a very important issue and one that thin client web browsing has brought sharply into focus. The fine art of blame allocation is an ITWorld article on this subject.

posted by Sean 5:13 AM

[Link] . . .

Epoz now does XHTML. Very nice.

posted by Sean 9:08 AM

[Link] . . .

This article on recent moves towards a standard binary encoding of XML contains the phrase "legacy XML".
I cannot believe how anyone would think it a good idea to have to go back to the back old days of funky binary decoders to understand the bits on the wire.
If XML bulk is killing the performance of your application (and I say "if" - you need to back that up with real data). (1) use standard text compression technology e.g. gzip. If that fails (2) consider not using XML at all.
I would prefer to see application specific syntaxes - like CSS or Relax NG compact syntax - bloom instead of letting the binary encoding genie back out of the bottle. Been there, bought the T-shirt, had troulble opening the packet and when I finally opened it, it was "corrupted" whatever that means :-)

posted by Sean 2:35 AM

[Link] . . .

Every John Steinbeck book on Amazon has "maths frameworking" in parentheses after the title. A publishers name? Sure looks weird.

posted by Sean 9:13 AM

[Link] . . .

Robert. C. Martin on the two edged sword known as "a good debugger".
Odd, but in my years programming Python, I have never felt the need to fire up the debugger that comes with it. I lived in a debugger when I was a C++ programmer.

posted by Sean 8:56 AM

[Link] . . .

Tim Bray points out a considered piece of language translation where the mechanical choice of 'titanic' has been eschewed for the more apposite 'herculean'. As Tim says, language is a slippery, slippery thing.
Douglas Hofstadter, of Godel, Escher, Bach fame, wrote an entire book centered around the translation of one 28 line French poem by Clément Marot.
Highly recommended if you are interested in language and the difficulty (futility?) of mechanizing the interpertation and translation of natural language.

posted by Sean 2:27 AM

[Link] . . .