Slashdot Mirror

The future of the Internet is in what I call "rational programming" derived from a revival of Bertrand Russell's Relation Arithmetic. Rational programming is a classically applicable branch of relation arithmetic's sub theory of quantum software (as opposed to the hardware-oriented technology of quantum computing). By classically applicable I mean it is applies to conventional computing systems -- not just quantum information systems. Rational programming will subsume what Tim Berners Lee calls the semantic web. The basic problem Tim (and just about everyone back through Bertrand Russell) fails to perceive is that logic is irrational. John McCarthy's signature line says it all about this kind of approach: "He who refuses to do arithmetic is doomed to talk nonsense." More on this a bit later, but first some history, because he who fails to learn from history is doomed to repeat its nonsense:

When I invented the precursor to Postscript (an audacious claim that I can back up -- it started as a replacement for NAPLPS which I proposed while Manager of Interactive Architectures for Viewdata Corp of America back in November of 1981 -- the Xerox PARC guys found my approach of what they called a "tokenized Forth" communication protocol to be an intriguing way to encode text and graphics), I was interested in having a Forth virtual machine migrate into silicon (ala Novix) so it could evolve from mere graphics rendering into a distributed Smalltalk VM environment (ala Squeak) as videotex terminal/personal computer capacities increased. But I was _not_ interested in object-oriented programming as the long-term semantics of distributed programming environments. (I still have some of the hardcopy of the communiques with Xerox PARC and others from this period.)

Rather, relational semantics were what I saw as the ultimate direction for distributed programming. I had a bit of a go at Tony Hoare's "communicating sequential processes" paradigm and its Transputer realization because he was, at least, starting with the hard problem of parallelism rather than making like the drunk looking for his keys under the light post the way everyone else seemed to be doing (and still are, save for Mozart, since threads, etc. are always an afterthought). But, because there were other hard problems like abstraction, transactions and persistence that he ignored, I christened his approach "Occam's Chainsaw Massacre" in my communiques (in honor of his distributed programming language "Occam") and dropped it in favor of relational programming, which has inherent parallelism resulting from both dependency and indeterminacy. (BTW: Dr. Hoare seems to have finally come to his senses about this issue.)

Unfortunately, the only researcher doing hardcore work on relational programming (meaning, getting to the root of relational semantics in a way that Codd had failed to do) at the time was Bruce MacLennan, then, of The Naval Postgraduate School, and he just didn't have the glamour of Alan Kay at places like Xerox PARC to attract the attention of guys like Steve Jobs. Bruce had a bit of a blind-spot, too, when it came to transactions and persistence, which I attempted to remedy by bringing David P. Reed's work on distributed transactions for the ARPAnet to him, but although he wrote a white paper on a predicate calculus (close to a relational) implementation of Reed's thesis (MIT/LCS/TR-205), he didn't really "get it", IMHO. Reed and MacLennan abandoned their work for other pursuits (ironically, Reed was chief scientist at Lotus while Notes was being developed but did not contribute his ideas on distributed synchronization to that development despite the fact that we had a mutual acquaintance from my Plato days by the name of Ray Ozzie -- so, I share some of the blame for this failure) even as Steve Jobs botched the embryonic object oriented world by abandoning Smalltalk and giving us, instead, a lineage consisting of Object Pascal on the Lisa/Mac which begat Objective C on Jobs's NeXT which begat Java at Sun via Naughton and Gosling's experience with NeXT.

This brings us to the present -- a world in which Javascript-based technologies like Tibet promise to not only salvage the object oriented aspect of the Internet from the birth defects of Jobs's spawn, but actually provide an advance over Smalltalk in the same lineage as CLOS and Self. But it is also a world in which there is growing confusion over the proper role of "metadata" in the form of XML -- particularly when it comes to speech acts and distributed inference. I would call Tibet "the next major Internet advance" except for the fact that the basic idea for a Tibet-like system has been around and well understood since the early 1980's. When it is finally released, Tibet (or a system like it) will put the Internet back on track. I call that a "recovery", not an "advance".

We are now poised to move forward with type inference based on full blown inference engines, thereby dispensing with the nonterminating arguments over statically vs dynamically typed languages that allowed Steve Jobs's spawn to get its nose in the tent. If you want to declare a "type" in a declarative language, just make another declaration and let the inference engine figure out what it can do with that information prior to run time. See how easy that was? Well, there is more to it than that, but not that much: Assertions have implications and assertions made prior to run time have implications prior to run time. Live with it and don't repeat the mistakes of the past.

The confusion over semantic webs, and the reason Berners Lee et al will fail, is essentially the same as the confusion that has beleaguered all inferential systems such as logic programming and "artificial intelligence" over the years: logic is irrational and the real world demands rationality -- otherwise nothing makes sense. By "rationality" I mean that reasoning must literally incorporate "ratios" -- or, as John McCarthy would put it, doing arithmetic so things make sense. By making sense, I mean there is a sense in which one interprets the sea of assertions that clearly dominates for a particular purpose. With logic not only are you limited to 0 and 1 as effective quantities; you have no adequate theoretic basis from which to derive more accurate quantities with which to make sense by taking ratios and determining which inferences are dominant.

Fuzzy logic and expert systems incorporating probabilities have typically failed because they are not based in the first principles of probability and statistics. As Gauss, the premiere probability theorist put it, "Mathematics is the study of relations." He didn't say, "Mathematics is the study of multisets." There are good reasons that relational databases, and not set manipulation languages, have come to dominate business applications -- and Gauss was aware of these differences when he began to derive his laws of probability. Subsequent axiomatizations of mathematics based on set theory were similarly misguided and have led to the idea that "fuzzy sets" are the way to introduce rationality into programming. Rather than sets, relations are the foundation, not just of mathematics but of rationality in the same sense that Gauss realized when he derived his theory of probability from the study of relations.

Rationality allows for judgment which is recognized as inherently fallible -- but which allows one to procede without exponentiating all possible paths of inference. Judgment also allows various identities to limit sharing of information to that needed -- thereby creating speech acts and a basis for rational measures of credibility associated with those identities. Since credit-rating is a degeneration of credibility, it should come as no shock that the invention of negative numbers, originating as they did with the Arabic invention of double entry account keeping, has its analog in something that might be called "logical debt" with which negative probabilities are associated.

And now we have come to the "quantum" aspect of rational programming. It is precisely the "credibility debt" aspect of rational programming that corresponds, in mathematical detail, to the various equations of quantum mechanics and their negative probability amplitudes. (Von Neumann's quantum logic failed to properly incorporate logical debt which has led to much confusion.) Logical debt is important to distributed programming for the same reason debt is important to financial networks. Logical debt is a way of handling poor synchronization of information flow in the same way that financial debt is a way of handling poor synchronization of cash flow. As in any rational system, there are both limits to credit and limits to credibilty that influence one's judgments and actions, including speech acts.

The object oriented folks may, in a sense, have the last laugh here because when we divide up inference into identities that engage in speech acts, we are reintroducing the notion of objects that hide information via exchange of speech act messages that can be thought of as "setters" (assertions) and "getters" (queries). However, I believe it is only fair to recognize that the excellent intuitions of Johan Dahl and Kristen Nygaard did need the added insights and rigor of philosophers like J. L. Austin and T. Etter.

The future of the Internet is in what I call "rational programming" derived from a revival of Bertrand Russell's Relation Arithmetic. Rational programming is a classically applicable branch of relation arithmetic's sub theory of quantum software (as opposed to the hardware-oriented technology of quantum computing). By classically applicable I mean it is applies to conventional computing systems -- not just quantum information systems. Rational programming will subsume what Tim Berners Lee calls the semantic web. The basic problem Tim (and just about everyone back through Bertrand Russell) fails to perceive is that logic is irrational. John McCarthy's signature line says it all about this kind of approach: "He who refuses to do arithmetic is doomed to talk nonsense." More on this a bit later, but first some history, because he who fails to learn from history is doomed to repeat its nonsense:

When I invented the precursor to Postscript (an audacious claim that I can back up -- it started as a replacement for NAPLPS which I proposed while Manager of Interactive Architectures for Viewdata Corp of America back in November of 1981 -- the Xerox PARC guys found my approach of what they called a "tokenized Forth" communication protocol to be an intriguing way to encode text and graphics), I was interested in having a Forth virtual machine migrate into silicon (ala Novix) so it could evolve from mere graphics rendering into a distributed Smalltalk VM environment (ala Squeak) as videotex terminal/personal computer capacities increased. But I was _not_ interested in object-oriented programming as the long-term semantics of distributed programming environments. (I still have some of the hardcopy of the communiques with Xerox PARC and others from this period.)

Rather, relational semantics were what I saw as the ultimate direction for distributed programming. I had a bit of a go at Tony Hoare's "communicating sequential processes" paradigm and its Transputer realization because he was, at least, starting with the hard problem of parallelism rather than making like the drunk looking for his keys under the light post the way everyone else seemed to be doing (and still are, save for Mozart, since threads, etc. are always an afterthought). But, because there were other hard problems like abstraction, transactions and persistence that he ignored, I christened his approach "Occam's Chainsaw Massacre" in my communiques (in honor of his distributed programming language "Occam") and dropped it in favor of relational programming, which has inherent parallelism resulting from both dependency and indeterminacy. (BTW: Dr. Hoare seems to have finally come to his senses about this issue.)

Unfortunately, the only researcher doing hardcore work on relational programming (meaning, getting to the root of relational semantics in a way that Codd had failed to do) at the time was Bruce MacLennan, then, of The Naval Postgraduate School, and he just didn't have the glamour of Alan Kay at places like Xerox PARC to attract the attention of guys like Steve Jobs. Bruce had a bit of a blind-spot, too, when it came to transactions and persistence, which I attempted to remedy by bringing David P. Reed's work on distributed transactions for the ARPAnet to him, but although he wrote a white paper on a predicate calculus (close to a relational) implementation of Reed's thesis (MIT/LCS/TR-205), he didn't really "get it", IMHO. Reed and MacLennan abandoned their work for other pursuits (ironically, Reed was chief scientist at Lotus while Notes was being developed but did not contribute his ideas on distributed synchronization to that development despite the fact that we had a mutual acquaintance from my Plato days by the name of Ray Ozzie -- so, I share some of the blame for this failure) even as Steve Jobs botched the embryonic object oriented world by abandoning Smalltalk and giving us, instead, a lineage consisting of Object Pascal on the Lisa/Mac which begat Objective C on Jobs's NeXT which begat Java at Sun via Naughton and Gosling's experience with NeXT.

This brings us to the present -- a world in which Javascript-based technologies like Tibet promise to not only salvage the object oriented aspect of the Internet from the birth defects of Jobs's spawn, but actually provide an advance over Smalltalk in the same lineage as CLOS and Self. But it is also a world in which there is growing confusion over the proper role of "metadata" in the form of XML -- particularly when it comes to speech acts and distributed inference. I would call Tibet "the next major Internet advance" except for the fact that the basic idea for a Tibet-like system has been around and well understood since the early 1980's. When it is finally released, Tibet (or a system like it) will put the Internet back on track. I call that a "recovery", not an "advance".

We are now poised to move forward with type inference based on full blown inference engines, thereby dispensing with the nonterminating arguments over statically vs dynamically typed languages that allowed Steve Jobs's spawn to get its nose in the tent. If you want to declare a "type" in a declarative language, just make another declaration and let the inference engine figure out what it can do with that information prior to run time. See how easy that was? Well, there is more to it than that, but not that much: Assertions have implications and assertions made prior to run time have implications prior to run time. Live with it and don't repeat the mistakes of the past.

The confusion over semantic webs, and the reason Berners Lee et al will fail, is essentially the same as the confusion that has beleaguered all inferential systems such as logic programming and "artificial intelligence" over the years: logic is irrational and the real world demands rationality -- otherwise nothing makes sense. By "rationality" I mean that reasoning must literally incorporate "ratios" -- or, as John McCarthy would put it, doing arithmetic so things make sense. By making sense, I mean there is a sense in which one interprets the sea of assertions that clearly dominates for a particular purpose. With logic not only are you limited to 0 and 1 as effective quantities; you have no adequate theoretic basis from which to derive more accurate quantities with which to make sense by taking ratios and determining which inferences are dominant.

Fuzzy logic and expert systems incorporating probabilities have typically failed because they are not based in the first principles of probability and statistics. As Gauss, the premiere probability theorist put it, "Mathematics is the study of relations." He didn't say, "Mathematics is the study of multisets." There are good reasons that relational databases, and not set manipulation languages, have come to dominate business applications -- and Gauss was aware of these differences when he began to derive his laws of probability. Subsequent axiomatizations of mathematics based on set theory were similarly misguided and have led to the idea that "fuzzy sets" are the way to introduce rationality into programming. Rather than sets, relations are the foundation, not just of mathematics but of rationality in the same sense that Gauss realized when he derived his theory of probability from the study of relations.

Rationality allows for judgment which is recognized as inherently fallible -- but which allows one to procede without exponentiating all possible paths of inference. Judgment also allows various identities to limit sharing of information to that needed -- thereby creating speech acts and a basis for rational measures of credibility associated with those identities. Since credit-rating is a degeneration of credibility, it should come as no shock that the invention of negative numbers, originating as they did with the Arabic invention of double entry account keeping, has its analog in something that might be called "logical debt" with which negative probabilities are associated.

And now we have come to the "quantum" aspect of rational programming. It is precisely the "credibility debt" aspect of rational programming that corresponds, in mathematical detail, to the various equations of quantum mechanics and their negative probability amplitudes. (Von Neumann's quantum logic failed to properly incorporate logical debt which has led to much confusion.) Logical debt is important to distributed programming for the same reason debt is important to financial networks. Logical debt is a way of handling poor synchronization of information flow in the same way that financial debt is a way of handling poor synchronization of cash flow. As in any rational system, there are both limits to credit and limits to credibilty that influence one's judgments and actions, including speech acts.

The object oriented folks may, in a sense, have the last laugh here because when we divide up inference into identities that engage in speech acts, we are reintroducing the notion of objects that hide information via exchange of speech act messages that can be thought of as "setters" (assertions) and "getters" (queries). However, I believe it is only fair to recognize that the excellent intuitions of Johan Dahl and Kristen Nygaard did need the added insights and rigor of philosophers like J. L. Austin and T. Etter.

The future of the Internet is in what I call "rational programming" derived from a revival of Bertrand Russell's Relation Arithmetic. Rational programming is a classically applicable branch of relation arithmetic's sub theory of quantum software (as opposed to the hardware-oriented technology of quantum computing). By classically applicable I mean it is applies to conventional computing systems -- not just quantum information systems. Rational programming will subsume what Tim Berners Lee calls the semantic web. The basic problem Tim (and just about everyone back through Bertrand Russell) fails to perceive is that logic is irrational. John McCarthy's signature line says it all about this kind of approach: "He who refuses to do arithmetic is doomed to talk nonsense." More on this a bit later, but first some history, because he who fails to learn from history is doomed to repeat its nonsense:

When I invented the precursor to Postscript (an audacious claim that I can back up -- it started as a replacement for NAPLPS which I proposed while Manager of Interactive Architectures for Viewdata Corp of America back in November of 1981 -- the Xerox PARC guys found my approach of what they called a "tokenized Forth" communication protocol to be an intriguing way to encode text and graphics), I was interested in having a Forth virtual machine migrate into silicon (ala Novix) so it could evolve from mere graphics rendering into a distributed Smalltalk VM environment (ala Squeak) as videotex terminal/personal computer capacities increased. But I was _not_ interested in object-oriented programming as the long-term semantics of distributed programming environments. (I still have some of the hardcopy of the communiques with Xerox PARC and others from this period.)

Rather, relational semantics were what I saw as the ultimate direction for distributed programming. I had a bit of a go at Tony Hoare's "communicating sequential processes" paradigm and its Transputer realization because he was, at least, starting with the hard problem of parallelism rather than making like the drunk looking for his keys under the light post the way everyone else seemed to be doing (and still are, save for Mozart, since threads, etc. are always an afterthought). But, because there were other hard problems like abstraction, transactions and persistence that he ignored, I christened his approach "Occam's Chainsaw Massacre" in my communiques (in honor of his distributed programming language "Occam") and dropped it in favor of relational programming, which has inherent parallelism resulting from both dependency and indeterminacy. (BTW: Dr. Hoare seems to have finally come to his senses about this issue.)

Unfortunately, the only researcher doing hardcore work on relational programming (meaning, getting to the root of relational semantics in a way that Codd had failed to do) at the time was Bruce MacLennan, then, of The Naval Postgraduate School, and he just didn't have the glamour of Alan Kay at places like Xerox PARC to attract the attention of guys like Steve Jobs. Bruce had a bit of a blind-spot, too, when it came to transactions and persistence, which I attempted to remedy by bringing David P. Reed's work on distributed transactions for the ARPAnet to him, but although he wrote a white paper on a predicate calculus (close to a relational) implementation of Reed's thesis (MIT/LCS/TR-205), he didn't really "get it", IMHO. Reed and MacLennan abandoned their work for other pursuits (ironically, Reed was chief scientist at Lotus while Notes was being developed but did not contribute his ideas on distributed synchronization to that development despite the fact that we had a mutual acquaintance from my Plato days by the name of Ray Ozzie -- so, I share some of the blame for this failure) even as Steve Jobs botched the embryonic object oriented world by abandoning Smalltalk and giving us, instead, a lineage consisting of Object Pascal on the Lisa/Mac which begat Objective C on Jobs's NeXT which begat Java at Sun via Naughton and Gosling's experience with NeXT.

This brings us to the present -- a world in which Javascript-based technologies like Tibet promise to not only salvage the object oriented aspect of the Internet from the birth defects of Jobs's spawn, but actually provide an advance over Smalltalk in the same lineage as CLOS and Self. But it is also a world in which there is growing confusion over the proper role of "metadata" in the form of XML -- particularly when it comes to speech acts and distributed inference. I would call Tibet "the next major Internet advance" except for the fact that the basic idea for a Tibet-like system has been around and well understood since the early 1980's. When it is finally released, Tibet (or a system like it) will put the Internet back on track. I call that a "recovery", not an "advance".

We are now poised to move forward with type inference based on full blown inference engines, thereby dispensing with the nonterminating arguments over statically vs dynamically typed languages that allowed Steve Jobs's spawn to get its nose in the tent. If you want to declare a "type" in a declarative language, just make another declaration and let the inference engine figure out what it can do with that information prior to run time. See how easy that was? Well, there is more to it than that, but not that much: Assertions have implications and assertions made prior to run time have implications prior to run time. Live with it and don't repeat the mistakes of the past.

The confusion over semantic webs, and the reason Berners Lee et al will fail, is essentially the same as the confusion that has beleaguered all inferential systems such as logic programming and "artificial intelligence" over the years: logic is irrational and the real world demands rationality -- otherwise nothing makes sense. By "rationality" I mean that reasoning must literally incorporate "ratios" -- or, as John McCarthy would put it, doing arithmetic so things make sense. By making sense, I mean there is a sense in which one interprets the sea of assertions that clearly dominates for a particular purpose. With logic not only are you limited to 0 and 1 as effective quantities; you have no adequate theoretic basis from which to derive more accurate quantities with which to make sense by taking ratios and determining which inferences are dominant.

Fuzzy logic and expert systems incorporating probabilities have typically failed because they are not based in the first principles of probability and statistics. As Gauss, the premiere probability theorist put it, "Mathematics is the study of relations." He didn't say, "Mathematics is the study of multisets." There are good reasons that relational databases, and not set manipulation languages, have come to dominate business applications -- and Gauss was aware of these differences when he began to derive his laws of probability. Subsequent axiomatizations of mathematics based on set theory were similarly misguided and have led to the idea that "fuzzy sets" are the way to introduce rationality into programming. Rather than sets, relations are the foundation, not just of mathematics but of rationality in the same sense that Gauss realized when he derived his theory of probability from the study of relations.

Rationality allows for judgment which is recognized as inherently fallible -- but which allows one to procede without exponentiating all possible paths of inference. Judgment also allows various identities to limit sharing of information to that needed -- thereby creating speech acts and a basis for rational measures of credibility associated with those identities. Since credit-rating is a degeneration of credibility, it should come as no shock that the invention of negative numbers, originating as they did with the Arabic invention of double entry account keeping, has its analog in something that might be called "logical debt" with which negative probabilities are associated.

And now we have come to the "quantum" aspect of rational programming. It is precisely the "credibility debt" aspect of rational programming that corresponds, in mathematical detail, to the various equations of quantum mechanics and their negative probability amplitudes. (Von Neumann's quantum logic failed to properly incorporate logical debt which has led to much confusion.) Logical debt is important to distributed programming for the same reason debt is important to financial networks. Logical debt is a way of handling poor synchronization of information flow in the same way that financial debt is a way of handling poor synchronization of cash flow. As in any rational system, there are both limits to credit and limits to credibilty that influence one's judgments and actions, including speech acts.

The object oriented folks may, in a sense, have the last laugh here because when we divide up inference into identities that engage in speech acts, we are reintroducing the notion of objects that hide information via exchange of speech act messages that can be thought of as "setters" (assertions) and "getters" (queries). However, I believe it is only fair to recognize that the excellent intuitions of Johan Dahl and Kristen Nygaard did need the added insights and rigor of philosophers like J. L. Austin and T. Etter.

The future of the Internet is in what I call "rational programming" derived from a revival of Bertrand Russell's Relation Arithmetic. Rational programming is a classically applicable branch of relation arithmetic's sub theory of quantum software (as opposed to the hardware-oriented technology of quantum computing). By classically applicable I mean it is applies to conventional computing systems -- not just quantum information systems. Rational programming will subsume what Tim Berners Lee calls the semantic web. The basic problem Tim (and just about everyone back through Bertrand Russell) fails to perceive is that logic is irrational. John McCarthy's signature line says it all about this kind of approach: "He who refuses to do arithmetic is doomed to talk nonsense." More on this a bit later, but first some history, because he who fails to learn from history is doomed to repeat its nonsense:

When I invented the precursor to Postscript (an audacious claim that I can back up -- it started as a replacement for NAPLPS which I proposed while Manager of Interactive Architectures for Viewdata Corp of America back in November of 1981 -- the Xerox PARC guys found my approach of what they called a "tokenized Forth" communication protocol to be an intriguing way to encode text and graphics), I was interested in having a Forth virtual machine migrate into silicon (ala Novix) so it could evolve from mere graphics rendering into a distributed Smalltalk VM environment (ala Squeak) as videotex terminal/personal computer capacities increased. But I was _not_ interested in object-oriented programming as the long-term semantics of distributed programming environments. (I still have some of the hardcopy of the communiques with Xerox PARC and others from this period.)

Rather, relational semantics were what I saw as the ultimate direction for distributed programming. I had a bit of a go at Tony Hoare's "communicating sequential processes" paradigm and its Transputer realization because he was, at least, starting with the hard problem of parallelism rather than making like the drunk looking for his keys under the light post the way everyone else seemed to be doing (and still are, save for Mozart, since threads, etc. are always an afterthought). But, because there were other hard problems like abstraction, transactions and persistence that he ignored, I christened his approach "Occam's Chainsaw Massacre" in my communiques (in honor of his distributed programming language "Occam") and dropped it in favor of relational programming, which has inherent parallelism resulting from both dependency and indeterminacy. (BTW: Dr. Hoare seems to have finally come to his senses about this issue.)

Unfortunately, the only researcher doing hardcore work on relational programming (meaning, getting to the root of relational semantics in a way that Codd had failed to do) at the time was Bruce MacLennan, then, of The Naval Postgraduate School, and he just didn't have the glamour of Alan Kay at places like Xerox PARC to attract the attention of guys like Steve Jobs. Bruce had a bit of a blind-spot, too, when it came to transactions and persistence, which I attempted to remedy by bringing David P. Reed's work on distributed transactions for the ARPAnet to him, but although he wrote a white paper on a predicate calculus (close to a relational) implementation of Reed's thesis (MIT/LCS/TR-205), he didn't really "get it", IMHO. Reed and MacLennan abandoned their work for other pursuits (ironically, Reed was chief scientist at Lotus while Notes was being developed but did not contribute his ideas on distributed synchronization to that development despite the fact that we had a mutual acquaintance from my Plato days by the name of Ray Ozzie -- so, I share some of the blame for this failure) even as Steve Jobs botched the embryonic object oriented world by abandoning Smalltalk and giving us, instead, a lineage consisting of Object Pascal on the Lisa/Mac which begat Objective C on Jobs's NeXT which begat Java at Sun via Naughton and Gosling's experience with NeXT.

This brings us to the present -- a world in which Javascript-based technologies like Tibet promise to not only salvage the object oriented aspect of the Internet from the birth defects of Jobs's spawn, but actually provide an advance over Smalltalk in the same lineage as CLOS and Self. But it is also a world in which there is growing confusion over the proper role of "metadata" in the form of XML -- particularly when it comes to speech acts and distributed inference. I would call Tibet "the next major Internet advance" except for the fact that the basic idea for a Tibet-like system has been around and well understood since the early 1980's. When it is finally released, Tibet (or a system like it) will put the Internet back on track. I call that a "recovery", not an "advance".

We are now poised to move forward with type inference based on full blown inference engines, thereby dispensing with the nonterminating arguments over statically vs dynamically typed languages that allowed Steve Jobs's spawn to get its nose in the tent. If you want to declare a "type" in a declarative language, just make another declaration and let the inference engine figure out what it can do with that information prior to run time. See how easy that was? Well, there is more to it than that, but not that much: Assertions have implications and assertions made prior to run time have implications prior to run time. Live with it and don't repeat the mistakes of the past.

The confusion over semantic webs, and the reason Berners Lee et al will fail, is essentially the same as the confusion that has beleaguered all inferential systems such as logic programming and "artificial intelligence" over the years: logic is irrational and the real world demands rationality -- otherwise nothing makes sense. By "rationality" I mean that reasoning must literally incorporate "ratios" -- or, as John McCarthy would put it, doing arithmetic so things make sense. By making sense, I mean there is a sense in which one interprets the sea of assertions that clearly dominates for a particular purpose. With logic not only are you limited to 0 and 1 as effective quantities; you have no adequate theoretic basis from which to derive more accurate quantities with which to make sense by taking ratios and determining which inferences are dominant.

Fuzzy logic and expert systems incorporating probabilities have typically failed because they are not based in the first principles of probability and statistics. As Gauss, the premiere probability theorist put it, "Mathematics is the study of relations." He didn't say, "Mathematics is the study of multisets." There are good reasons that relational databases, and not set manipulation languages, have come to dominate business applications -- and Gauss was aware of these differences when he began to derive his laws of probability. Subsequent axiomatizations of mathematics based on set theory were similarly misguided and have led to the idea that "fuzzy sets" are the way to introduce rationality into programming. Rather than sets, relations are the foundation, not just of mathematics but of rationality in the same sense that Gauss realized when he derived his theory of probability from the study of relations.

Rationality allows for judgment which is recognized as inherently fallible -- but which allows one to procede without exponentiating all possible paths of inference. Judgment also allows various identities to limit sharing of information to that needed -- thereby creating speech acts and a basis for rational measures of credibility associated with those identities. Since credit-rating is a degeneration of credibility, it should come as no shock that the invention of negative numbers, originating as they did with the Arabic invention of double entry account keeping, has its analog in something that might be called "logical debt" with which negative probabilities are associated.

And now we have come to the "quantum" aspect of rational programming. It is precisely the "credibility debt" aspect of rational programming that corresponds, in mathematical detail, to the various equations of quantum mechanics and their negative probability amplitudes. (Von Neumann's quantum logic failed to properly incorporate logical debt which has led to much confusion.) Logical debt is important to distributed programming for the same reason debt is important to financial networks. Logical debt is a way of handling poor synchronization of information flow in the same way that financial debt is a way of handling poor synchronization of cash flow. As in any rational system, there are both limits to credit and limits to credibilty that influence one's judgments and actions, including speech acts.

The object oriented folks may, in a sense, have the last laugh here because when we divide up inference into identities that engage in speech acts, we are reintroducing the notion of objects that hide information via exchange of speech act messages that can be thought of as "setters" (assertions) and "getters" (queries). However, I believe it is only fair to recognize that the excellent intuitions of Johan Dahl and Kristen Nygaard did need the added insights and rigor of philosophers like J. L. Austin and T. Etter.

This is pretty interesting. It's pretty hard to track down information about people, especially if they don't have much of a Net presence, or you simply don't have enough starting data. I'd really like to be able to turn up interesting data hidden several layers deep, and be able to search for things with a vague query that involves all sorts of peripheral identifiers. For people, it might be high school attended and current company, maybe other people they might know.

Hmm. Definitely interesting. Although I doubt it will be able to find my father's brother's nephew's cousin's former room-mate. ;)

Oh, for the Semantic Web - I saw a couple of stories here before, but here's something that might be informative:

Semantic Web Roadmap (http://www.w3.org/DesignIssues/Semantic.html) - also by Tim Berners-Lee, last modified 1998/10/14.

This is pretty interesting. It's pretty hard to track down information about people, especially if they don't have much of a Net presence, or you simply don't have enough starting data. I'd really like to be able to turn up interesting data hidden several layers deep, and be able to search for things with a vague query that involves all sorts of peripheral identifiers. For people, it might be high school attended and current company, maybe other people they might know.

Hmm. Definitely interesting. Although I doubt it will be able to find my father's brother's nephew's cousin's former room-mate. ;)

Oh, for the Semantic Web - I saw a couple of stories here before, but here's something that might be informative:

Semantic Web Roadmap (http://www.w3.org/DesignIssues/Semantic.html) - also by Tim Berners-Lee, last modified 1998/10/14.

LTSS 1.0 could support WAV, MP3

s/MP3/Ogg Vorbis/

GIF

s/GIF/PNG/ because PNG is better documented and supports 24-bit color and alpha transparency. You partially address this with

TIFF

but s/TIFF/PNG/ because even without TIFF's LZW codec, TIFF is much larger than PNG and not as well standardized.

Text/ASCII

Non-European language advocates would complain.

Text/Unicode

Better. Thank you. This solves the script issue, but in what natural language would information be stored? How is it a valid assumption that future generations can read format specs written in US English of A.D. 2001 or in UK English of A.D. 2001?

HTML version whatever

Make sure it's run through W3C's HTML Validator if you want to archive it. MSHTML is a Bad Thing.

and perhaps even Java for interpretation of abirtrary [sic] file formats.

The Java(TM) langauge does not have the wealth of alternative implementations that the C language has. Both are nearly Turing complete (full Turing completeness requires unbounded storage) and equally fast when compiled to a native instruction set.

Some Accessibility links:

• IBM
• W3C/WAI
• Evil Empire (Hey, it's one of the better resources)

Tim Berners-Lee explicitly states that Andreesen's Mosaic was the first browser to display inline images on his homepage FAQ.

C'mon, let's get it right. Mosaic was not the first graphical Web browser. That honor belongs to WorldWideWeb.app, written by Tim Berners-Lee in Objective C on NeXTStep. This FAQ item gives the story: First, there was WorldWideWeb.app for NeXTStep, then ViolaWWW, Erwise and Midas for Unix. Marc Andreessen and Eric Bina then wrote Mosaic for Unix after seeing ViolaWWW and Midas. Later, other NCSA people ported Mosaic to the PC, and it came out about the same time as Cello on the PC.

So, Mosaic was not the first at anything. Not the first graphical Web browser, not the first on Unix, and tied for first on the PC. Let's get it straight!

This is exactly what the Platform for Privacy Preferences (P3P) is : a way to state privacy policy in XML. It's great in the sense that we won't have to wade through legalese gibberish, but many are worried that there will be a push to automate entirely the verification of a privacy policy (and myself, I'd rather not have MS software making my privacy decisions for me). That's what the poster above was referring to when mentioning the new icon in IE6, which apprently will have native P3P support.

Of course, a privacy policy, whether machine or lawyer readable, doesn't actually prove that a company behaves as stated. This is true also for the likes of TRUSTe - just because a site has the logo doesn't tell you jack about what that site's practices really are, it merely tells you they were prepared to stump up the five grand for the logo. And what happens when a site is found to be in breach of it's own policy, as rubber-stamped by TRUSTe? Nothing. As far as I am aware, TRUSTe have never revoked a site's membership, despite several incidents where companies were found out.

I don't see seal schemes or P3P solving the underlying problems. I'd like to see privacy policies become more like true contracts, with the full force of the law on your side when there's a breach. Course, that's not likely to happen anytime soon in the US, given the current administration's reluctance to take steps which would "impact the US economy". You could have used that same argument to lobby against the abolition of slavery, but I think I'm getting off topic now....

Jeff works on the DataGlyph technology. I work on applications of it. See http://www.xerox.com/flowport for my application, which lets you put a sheet with DataGlyphs on your document, drop it in a copier, and get out a paper icon for the document (stored on a WebDAV or other network server). You put the paper icon back in, and press copy to get a copy, type an e-mail address to e-mail it, etc. It's like an electronic version of the paper document, but on paper. We call it a "Document Token". (There has been previous SlashDot discussion of Document Tokens and other applications of DataGlyphs, but I can't find it either).

We're also very interested in open standards, and participate in a variety of standards organizations on this and related technologys. For example I'm on the W3C XForms committee, designing the next generation of web forms, and paper is one of the new "devices" that is being targeted (along with voice, pdas, phones, etc.). Check it out and send your comments to the www-forms mailing list! As we said when XForms was launched:

For the Web to become a truly ubiquitous computing interface, it must move beyond the desktop. XForms and other W3C open standards will make it easy to create and to use rich, interactive Web documents and services on a wide variety of user interfaces -- graphical, voice, and paper.

Jeff works on the DataGlyph technology. I work on applications of it. See http://www.xerox.com/flowport for my application, which lets you put a sheet with DataGlyphs on your document, drop it in a copier, and get out a paper icon for the document (stored on a WebDAV or other network server). You put the paper icon back in, and press copy to get a copy, type an e-mail address to e-mail it, etc. It's like an electronic version of the paper document, but on paper. We call it a "Document Token". (There has been previous SlashDot discussion of Document Tokens and other applications of DataGlyphs, but I can't find it either).

We're also very interested in open standards, and participate in a variety of standards organizations on this and related technologys. For example I'm on the W3C XForms committee, designing the next generation of web forms, and paper is one of the new "devices" that is being targeted (along with voice, pdas, phones, etc.). Check it out and send your comments to the www-forms mailing list! As we said when XForms was launched:

For the Web to become a truly ubiquitous computing interface, it must move beyond the desktop. XForms and other W3C open standards will make it easy to create and to use rich, interactive Web documents and services on a wide variety of user interfaces -- graphical, voice, and paper.

No, you are wrong. XHTML requires lowercase as evidenced by the W3 XHTML 1.0 spec section 4.2 aptly titled 'Element and attribute names must be in lower case'.

-----
"People who bite the hand that feeds them usually lick the boot that kicks them"

I know that this isn't terribly helpful, but I actually found this out a few months ago. The bummer is that I can't find it again. It was a page affiliated with Tim Berners-Lee or the W3C. (Or was it on CERN's site?) But it was the #1, very first, no-question-about-it page on the web. It exists. It's out there. Anybody know where?

-Waldo

I know that this isn't terribly helpful, but I actually found this out a few months ago. The bummer is that I can't find it again. It was a page affiliated with Tim Berners-Lee or the W3C. (Or was it on CERN's site?) But it was the #1, very first, no-question-about-it page on the web. It exists. It's out there. Anybody know where?

-Waldo

We weren't exactly the first site on the Web. Try http://www.w3.org/History/.

Yes, I realise this specific story is a joke, the same of the colour space just caught me eye.

At Mr. Berners-Lee's homepage there is an FAQ that includes some Examples of early WWW hypertext. It would appear to be from 1990 or 1991. That's about as early as it gets I would think!

At Mr. Berners-Lee's homepage there is an FAQ that includes some Examples of early WWW hypertext. It would appear to be from 1990 or 1991. That's about as early as it gets I would think!

At Mr. Berners-Lee's homepage there is an FAQ that includes some Examples of early WWW hypertext. It would appear to be from 1990 or 1991. That's about as early as it gets I would think!

Sorry guys, NSCA Mosaic was not the first Web browser. It wasn't even the first GUI Web browser. Instead, that honor goes to WorldWideWeb.app on NeXTSTEP.

Therefore, the oldest Web pages may still exist on Tim Berners-Lee's old NeXT cube, but it's not on the Web anymore. Thinking back to the first Web page you saw doesn't help you find the oldest page still on the Web, unless it's still available.

The DOM is well documented at W3C. At least if all you need is a reference. The whole point of Mozilla is that you should be able to use open standards to write your web pages, not vendor specific standards.

preview is your friend.

Chris Cothrun
Curator of Chaos

Recently I ran into a problem with IIS because although it claimed to support the W3C Extended Log File format, Microsoft "forgot" to make it extendable as both the name implies and as written into the specification. I was told by the $250 support call that I made that because the specification didn't include a provision for implementation, it was "supportd" only by writing either an ISAPI filter or COM logging module. It needs to be noted that no specification includes provisions for implementation, just the rules that must be adhered to in order to claim compatability or support for. Imagine my surprise when the development tools needed to enable the "supported" feature did not come bundled with IIS, (i.e.,, VC++). By using the Microsoft support engineer's logic, providing someone with VC++ constitutes support for the HTTP 1.1 protocol (RFC 2616) as well. Why even waste time developing IIS? Apache and Netscape both require a 3 word modification to config file to accomplish what I needed to do. Something that can be completed by any novice adminstrator. IIS, on the other hand, requires several thousands of lines of code to be written and compiled by a software engineer with a toolkit not bundled with the product? How does this qualify as a supported feature? For a feature to be supported, from my perspective, the line is drawn when someone with administrative priveleges or less can make a parameter change with a config file or utility. Requiring a software engineer to write compilable code with an unbundled software development kit does not constitute support. Now Microsoft wants me to pay their professional services group to write the code necessary to make IIS compatible with the specification the product literature already claims it is. Is it any wonder why so many tech savvy people despise working with Microsoft server tools? What is Microsoft doing to change this perception? Please comment...

doomed to failure until someone implements something like the Dewey Decimal System for web pages

Yes, we're stuffed -- but Dewey Decimal isn't the answer (we can do a lot better than that).

There's an initiative around that's gaining considerable momentum - the Semantic Web. It starts from one bright idea by one guy, but as the guy in question is Tim B-L, then he gets listened to. There are solutions to all this. We've barely started on what we could easily achieve for indexing the web, without even trying for the really hard stuff.

Once basic semantic level indexing becoms commonplace, through tools like Dublin Core, then take a look at ontological descriptions and projects like DAML.

There's a huge amount happening in this field research-wise, it just hasn't hit the punter's web yet.

If you're looking for a standard "vocabulary" to use in the context of RDF, W3's RDF FAQ has a link to suggestions about how to implement the Dublin Core tags via RDF. For a more specific and extensive vocabulary, you're probably right - there's very little agreement about what sort of standard to use. It's kind of ironic actually; libraries have been using one of two different organizational systems (Dewey or LOC) for roughly a century, either of which seems like it would lend itself handily to indexing the web topically. Yet in the quickest-growing body of knowledge on the planet, nobody wants either of those, and nobody seems to be able to agree on anything new either.

The neatest way to improve this feature would be to implement the W3C's Composite Capabilities/Preferences Profiles specification. It's still under development now, but you can read an old, old article I did years ago for the HTML Writers Guild's newsletter, at ccpp.org, or you can just check out the W3C's web site. There's a public draft currently available. --Kynn

Timely article. W3C just advanced a working draft of CC/PP to Last Call.

It stands for Composite Capabilities/Preferences Profiles. It's a language that your browser could use to describe its capabilities and your preferences, e.g. "32-bit display, 800x600 browser window, PPC hardware, no applets."

The idea is, of course you want the server to know what you've got, so it doesn't send you useless content. Like it or not, your browser will be having deeper conversations with servers, pretty soon.

...On the other hand, this language (CC/PP) looks too complicated to use.

I'm a web developer. If I'm on the server, I want to deliver content to the browser and let the browser format it appropriately, taking into account resolution, window size, color depth, user colorblindness, and so on. Heaven knows I don't want to write an IF statement for every possible pipe size.

There just needs to be a way for me to write "you've got a choice-- low-bandwidth or high-bandwidth media; 8-bit or 32-bit images" using tags in my HTML, and the user's browser should decide what to do with that information. Often it can just pick the best alternative for that client. If not, it can always just render two links and let the user choose.

Screen size is a matter of "form". A "short fat screen" has a different form factor than a "tall skinny screen", right? A properly designed web page is not constrained to any one resolution or window size. CSS has provisions for layout boxes defined as a %-age of the parent element and for floating elements. If I resize my browser window, the web page should reflow into the available content area, not be locked to a particular presentation.

Do you really want to build a site 4 times to accommodate 4 different ways a user might access it? What happens if a 5th method is developed — do you retrofit all your existing sites? No! Build the site correctly and you only have to do it once!

Remember when most sites had a "text only" link? Maybe if the browsers make it easy to identify text-only users then that kind of duality can come back.

There never was a duality, except when lazy web designers were involved. Web content is primarily textual. If you have inline images or other media, you're expected to provide ALT text and similar fallback mechanisms. Graceful degradation and device independence are the key, but the concept seems to have flown right over the heads of an entire generation of dee-zyne-ers.

Imagine never having to answer stupid questions like "flash or html?" "800x600 or 1024x768?"

Imagine sending your content in a universally accessible fashion, rather than a proprietary format that requires a plugin. Imagine designing a site correctly so that it automatically fits any size browser with no extra work or finagling on your part.

Its possible that based on the connection speed, you could default modem users to the HTML site and broadband customers to the flash site (of course, with links to the opposite choice).

If you recognize here that people want a choice, why don't you recognize their choices (system preferences) in other areas as well?

You could also arrange the tables so people with smaller screen sizes are scrolling left to right and people with large screen sizes aren't forced to scroll down a website that fits into the first three inches of their screen.

See above. A good design accommodates variable screen sizes without the need for "detection scripts" and such. You don't need to know the user's screen size.

I do think there is something else they should flag...system color scheme. I use a darker scheme where my text is white and my workspace is black. On many websites with hardcoded white background I can't read a thing. I usually end up having to disable them. It would be nice if a website could ask my browser what my default text color is and send out the appropriate background.

Similar functionality exists in CSS. If the site uses your system colors it will behave as you describe.

SVG (Scalable Vector Graphics) is the preferred W3C standard for vector graphics. I recommend converting to this standard instead. You can get Adobe's free SVG viewer for Netscape/IE (Mac/Windows-only though). Mozilla also comes with SVG support (although you usually have to add it in yourself from the codebase -- haven't checked the latest 0.8 for inclusion though). There are numerous programs for UNIX that do SVG import/export (almost all the major Qt/GTK+ vector graphics programs do), and support seems to be increasing in Windows programs (although I haven't seen it in Visio, but I might be one version back now).

-- Bryan "TheBS" Smith

SVG (Scalable Vector Graphics) is the preferred W3C standard for vector graphics. I recommend converting to this standard instead. You can get Adobe's free SVG viewer for Netscape/IE (Mac/Windows-only though). Mozilla also comes with SVG support (although you usually have to add it in yourself from the codebase -- haven't checked the latest 0.8 for inclusion though). There are numerous programs for UNIX that do SVG import/export (almost all the major Qt/GTK+ vector graphics programs do), and support seems to be increasing in Windows programs (although I haven't seen it in Visio, but I might be one version back now).

-- Bryan "TheBS" Smith

HTTP already has Content-Encoding: gzip . But the bulk of HTTP transfer (on a kilobyte basis) is already tightly compressed (PNG and JPEG images; MP3 audio; Flash, MNG, and MPEG animations; bzip2 tarballs) so this will help only for HTML and MIDI.

It would obviously require a compatible browser

Or a compatible proxy. But AFAIK Mozilla and IE (two biggest browsers) already support it.

In a word, "what?" As in, what are people thinking when the write tirades *against* open standards bodies for computing technology?

Here are some that have worked, and made your lives a whole lot better:

RFCs
POSIX/IEEE
HTTP/HTML
ASCII/ISO 8859
ANSI C

And that's just to name a few that immediately came to mind. Note that some of them had coporate sponsorship, some are truly community reviewed, and some are a mixture. But standards are essential for ever moving *beyond* the technology of today. If we didn't have a standard C, then people will still be arguing over how to improve C, rather than creating new languages.

Really, standards shouldn't evolve that much. And people shouldn't wait to get them perfect. Agree on something that mostly works, use it, and move on.

Umm, this post is somewhat at odds with what I understood SOAP to be. Isn't it an open standard? There's a spec here, and it certainly doesn't appear to be 'single vendor' as you put it (see here)
Q: Am I seriously missing something here?

SOAP is not a single-vendor solution anymore. SOAP 1.0 was, but with the help of IBM and a few others version 1.1 became a very powerful and flexible (read: somewhat difficult to use, at least when you want to do more than just RPC) framework for platform-independent communication, and is now controlled by the W3C. In other words: I like it. You can read the specs here.

Lets clear the smoke.

If "two" (forget more for a second) "alien-things" happened to agree to use a messaging protocol, such as SOAP, well, right there we would have a minor (but cosmic , considering that "alien-things" are involved) miracle , since apparently they communicated their agreement without a common communication means. (No. Telepathy doesn't count.)

Smoke: XML messaging (SOAP) works miracles!

Fact: "[A]lien-things" first need a common mechanism for reaching consensus regarding communication of information..

So lets say they belong to the Inter-Galactic Alliance of Geeky "Alien-Things" [I-GAGA-T(TM)], governed by the I-GAGA-T's strict policies regarding communication means deployment. [Kinda like the saying "lets all use HTTP"]. Then, our two brave "alien-things", charter members of I-GAGA-T (affectionately known to each other as GAGAs), decide to communicate using SOAP, at which point they have fulfilled "the ONLY requirement when doing client/server" according to their recently hired communication consultant, an Earthling named garoush . [Believe me folks, I am not making this up. A true story from the GAGA archives.]

But have they?

No. One of the GAGAs decides to send a message using SOAP to its newly acquired friend! So the trusty (and somewhat rusty) SOAP client is fired up and the message is sent. And guess what? Promptly comes the standard error reply: "Message received, NOT understood. Ca va?"

Put simply, using SOAP, two or more 'alien-things' can communicate to each other as long as they agree on the SOAP protocol - which is the ONLY requirement when doing client/server using SOAP.

So, put simply, the above is a false statement.

[And this point in the story, we find an agitated and nervous garoush, furiously sending SOAPy messages to Earth: "<help>Me!!</help>" -- Lets hope that back on Earth, garoush's friends have first agreed on the Rescue-Message-Format! (But maybe they didn't, hey garoush? "Just use SOAP" he used to say back on Earth. Well ... Just use SOAP then :) )]

SOAP, and XML-RPC, both provide a means for one GAGA to send messages to another GAGA, even if the two GAGA have discovered each other for the very first time. And this messaging protocol , based on the well-understood [there!] request-reply paradigm, and utilizing a standard XML-based message container , delivers SOAP-compliant XML messages from the sender to the receiver.

So as garoush learned/will-learn [funny thing, this space-time continuum] from his consulting gig to the GAGAs, <help>Me!</help> is not defined. For the content of the message, which delivers information from garoush back to Earth, to be understood by the recipient's), he and his hoped-for-rescuers would have first needed to agree on the format of encoding information in your SOAPy messages.

Sure CORBA, DCOM, COM+, Java, etc. allow you to enable two different components to talk to each other, but those technologies do it in such a way that you must have a 'piece' of the server (called the client) to be delivered and used by the client developer. Thus, to talk with a 'server' you must meet the needs of the 'server' when using CORBA, DCOM, COM+, Java, etc. With SOAP, this is all eliminated. As long as the server publishes its API via the SOAP protocol, I can write my client to talk with the server using what ever I want. This frees me from having to 'embed' in my client a piece of the server -- thus there is no longer any 'hard-coupling' between two 'things'.

[We'll skip the fact that SOAP, CORBA, [D]COM[+], and "Java" are a rather orthogonal set of technologies ...]

What is apparently not understood by garoush is that CORBA, DCOM, COM+, Java RMI, do much much more than just simply pass messages from one GAGA to another. [I recommend this great book written specifically for GAGAs for more information on what real (i.e. working) Inter-GAGA Communication Protocols require to function. (Check out the GAGAs on the cover!)] .

Lets just take Java's RMI as an example. What's this with RMI you say? Why didn't they call it Java RPC? I'm glad you asked. See the 'M' in RMI? That's a method, which is a procedure bound to an object. The P in RPC refers to a procedure, which is not necessarily bound to anything. To invoke a method of an object, you first need to get a handle on the object, a remote reference. Any object you say? No. Objects which have been registered with a Registry/Directory Service ( UDDI anyone?) Then you pass the method invocation message to the remote object and a bit of infrastructure on the receiving end maps your method invocation message to an actual method call on the specific object you are invoking. This sub-process of mapping your messages to actual method calls on a specific object uses a messaging protocol which is analogous to what SOAP specifies.

So:

Smoke: SOAP (& XML-RPC) are distributed object technologies! [This goes beyond Smoke and verges on GAGA humor..]

Fact: SOAP is a Simple Xml-based Messaging Protocol (SXMP)

Fact: By the time you have implemented a true Simple Object Access Protocol using a SXMP, you will have something that will look awfully close to RMI. (With the exception that RMI doesn't shuffle needlessly verbose ASCII bits through its system-level plumbing, but your SOAP does.)

In short, by the time you have provided the functionality of an RMI mechanism, such as Java RMI, using SOAP (or any RPC mechanism), you will have accomplished, by the prerequisite functionality of the task at hand, a fairly complex bit of software engineering. Congratulations! (CORBA? Oh boy ...)

In short, using SOAP, we now enable a true 'smart' data-exchange-protocol between two systems such that development is now at the level of "data-exchange" rather than API, SDK, language, etc.

No. More likely, you will realize that having standardized on the data-exchange, you have in effect delegated the complexity of building a distributed object system to the client as opposed to the infrastructure.

Now that is smart. [Good going there Bill!]

[Meanwhile, back on Earth, garoush's friends and would-be rescuers [will] happen upon a long forgotten SOAP Server log file. There, buried among other debug and error messages is the messaging logging the error message the SOAP server sent back to garoush back on planet X. "Ouch" says one of garoush's friends. "I hope he is OK". Now, isn't it just great that XML messages are human readable? (Its too back Servers aren't human -- damn shameful waste of all that human readable information!)]

Smoke: SOAP/XML is a great leap forward!

Fact: Bubble Economies produce Bubble Technologies .

Lets clear the smoke.

If "two" (forget more for a second) "alien-things" happened to agree to use a messaging protocol, such as SOAP, well, right there we would have a minor (but cosmic , considering that "alien-things" are involved) miracle , since apparently they communicated their agreement without a common communication means. (No. Telepathy doesn't count.)

Smoke: XML messaging (SOAP) works miracles!

Fact: "[A]lien-things" first need a common mechanism for reaching consensus regarding communication of information..

So lets say they belong to the Inter-Galactic Alliance of Geeky "Alien-Things" [I-GAGA-T(TM)], governed by the I-GAGA-T's strict policies regarding communication means deployment. [Kinda like the saying "lets all use HTTP"]. Then, our two brave "alien-things", charter members of I-GAGA-T (affectionately known to each other as GAGAs), decide to communicate using SOAP, at which point they have fulfilled "the ONLY requirement when doing client/server" according to their recently hired communication consultant, an Earthling named garoush . [Believe me folks, I am not making this up. A true story from the GAGA archives.]

But have they?

No. One of the GAGAs decides to send a message using SOAP to its newly acquired friend! So the trusty (and somewhat rusty) SOAP client is fired up and the message is sent. And guess what? Promptly comes the standard error reply: "Message received, NOT understood. Ca va?"

Put simply, using SOAP, two or more 'alien-things' can communicate to each other as long as they agree on the SOAP protocol - which is the ONLY requirement when doing client/server using SOAP.

So, put simply, the above is a false statement.

[And this point in the story, we find an agitated and nervous garoush, furiously sending SOAPy messages to Earth: "<help>Me!!</help>" -- Lets hope that back on Earth, garoush's friends have first agreed on the Rescue-Message-Format! (But maybe they didn't, hey garoush? "Just use SOAP" he used to say back on Earth. Well ... Just use SOAP then :) )]

SOAP, and XML-RPC, both provide a means for one GAGA to send messages to another GAGA, even if the two GAGA have discovered each other for the very first time. And this messaging protocol , based on the well-understood [there!] request-reply paradigm, and utilizing a standard XML-based message container , delivers SOAP-compliant XML messages from the sender to the receiver.

So as garoush learned/will-learn [funny thing, this space-time continuum] from his consulting gig to the GAGAs, <help>Me!</help> is not defined. For the content of the message, which delivers information from garoush back to Earth, to be understood by the recipient's), he and his hoped-for-rescuers would have first needed to agree on the format of encoding information in your SOAPy messages.

Sure CORBA, DCOM, COM+, Java, etc. allow you to enable two different components to talk to each other, but those technologies do it in such a way that you must have a 'piece' of the server (called the client) to be delivered and used by the client developer. Thus, to talk with a 'server' you must meet the needs of the 'server' when using CORBA, DCOM, COM+, Java, etc. With SOAP, this is all eliminated. As long as the server publishes its API via the SOAP protocol, I can write my client to talk with the server using what ever I want. This frees me from having to 'embed' in my client a piece of the server -- thus there is no longer any 'hard-coupling' between two 'things'.

[We'll skip the fact that SOAP, CORBA, [D]COM[+], and "Java" are a rather orthogonal set of technologies ...]

What is apparently not understood by garoush is that CORBA, DCOM, COM+, Java RMI, do much much more than just simply pass messages from one GAGA to another. [I recommend this great book written specifically for GAGAs for more information on what real (i.e. working) Inter-GAGA Communication Protocols require to function. (Check out the GAGAs on the cover!)] .

Lets just take Java's RMI as an example. What's this with RMI you say? Why didn't they call it Java RPC? I'm glad you asked. See the 'M' in RMI? That's a method, which is a procedure bound to an object. The P in RPC refers to a procedure, which is not necessarily bound to anything. To invoke a method of an object, you first need to get a handle on the object, a remote reference. Any object you say? No. Objects which have been registered with a Registry/Directory Service ( UDDI anyone?) Then you pass the method invocation message to the remote object and a bit of infrastructure on the receiving end maps your method invocation message to an actual method call on the specific object you are invoking. This sub-process of mapping your messages to actual method calls on a specific object uses a messaging protocol which is analogous to what SOAP specifies.

So:

Smoke: SOAP (& XML-RPC) are distributed object technologies! [This goes beyond Smoke and verges on GAGA humor..]

Fact: SOAP is a Simple Xml-based Messaging Protocol (SXMP)

Fact: By the time you have implemented a true Simple Object Access Protocol using a SXMP, you will have something that will look awfully close to RMI. (With the exception that RMI doesn't shuffle needlessly verbose ASCII bits through its system-level plumbing, but your SOAP does.)

In short, by the time you have provided the functionality of an RMI mechanism, such as Java RMI, using SOAP (or any RPC mechanism), you will have accomplished, by the prerequisite functionality of the task at hand, a fairly complex bit of software engineering. Congratulations! (CORBA? Oh boy ...)

In short, using SOAP, we now enable a true 'smart' data-exchange-protocol between two systems such that development is now at the level of "data-exchange" rather than API, SDK, language, etc.

No. More likely, you will realize that having standardized on the data-exchange, you have in effect delegated the complexity of building a distributed object system to the client as opposed to the infrastructure.

Now that is smart. [Good going there Bill!]

[Meanwhile, back on Earth, garoush's friends and would-be rescuers [will] happen upon a long forgotten SOAP Server log file. There, buried among other debug and error messages is the messaging logging the error message the SOAP server sent back to garoush back on planet X. "Ouch" says one of garoush's friends. "I hope he is OK". Now, isn't it just great that XML messages are human readable? (Its too back Servers aren't human -- damn shameful waste of all that human readable information!)]

Smoke: SOAP/XML is a great leap forward!

Fact: Bubble Economies produce Bubble Technologies .

Lets clear the smoke.

If "two" (forget more for a second) "alien-things" happened to agree to use a messaging protocol, such as SOAP, well, right there we would have a minor (but cosmic , considering that "alien-things" are involved) miracle , since apparently they communicated their agreement without a common communication means. (No. Telepathy doesn't count.)

Smoke: XML messaging (SOAP) works miracles!

Fact: "[A]lien-things" first need a common mechanism for reaching consensus regarding communication of information..

So lets say they belong to the Inter-Galactic Alliance of Geeky "Alien-Things" [I-GAGA-T(TM)], governed by the I-GAGA-T's strict policies regarding communication means deployment. [Kinda like the saying "lets all use HTTP"]. Then, our two brave "alien-things", charter members of I-GAGA-T (affectionately known to each other as GAGAs), decide to communicate using SOAP, at which point they have fulfilled "the ONLY requirement when doing client/server" according to their recently hired communication consultant, an Earthling named garoush . [Believe me folks, I am not making this up. A true story from the GAGA archives.]

But have they?

No. One of the GAGAs decides to send a message using SOAP to its newly acquired friend! So the trusty (and somewhat rusty) SOAP client is fired up and the message is sent. And guess what? Promptly comes the standard error reply: "Message received, NOT understood. Ca va?"

Put simply, using SOAP, two or more 'alien-things' can communicate to each other as long as they agree on the SOAP protocol - which is the ONLY requirement when doing client/server using SOAP.

So, put simply, the above is a false statement.

[And this point in the story, we find an agitated and nervous garoush, furiously sending SOAPy messages to Earth: "<help>Me!!</help>" -- Lets hope that back on Earth, garoush's friends have first agreed on the Rescue-Message-Format! (But maybe they didn't, hey garoush? "Just use SOAP" he used to say back on Earth. Well ... Just use SOAP then :) )]

SOAP, and XML-RPC, both provide a means for one GAGA to send messages to another GAGA, even if the two GAGA have discovered each other for the very first time. And this messaging protocol , based on the well-understood [there!] request-reply paradigm, and utilizing a standard XML-based message container , delivers SOAP-compliant XML messages from the sender to the receiver.

So as garoush learned/will-learn [funny thing, this space-time continuum] from his consulting gig to the GAGAs, <help>Me!</help> is not defined. For the content of the message, which delivers information from garoush back to Earth, to be understood by the recipient's), he and his hoped-for-rescuers would have first needed to agree on the format of encoding information in your SOAPy messages.

Sure CORBA, DCOM, COM+, Java, etc. allow you to enable two different components to talk to each other, but those technologies do it in such a way that you must have a 'piece' of the server (called the client) to be delivered and used by the client developer. Thus, to talk with a 'server' you must meet the needs of the 'server' when using CORBA, DCOM, COM+, Java, etc. With SOAP, this is all eliminated. As long as the server publishes its API via the SOAP protocol, I can write my client to talk with the server using what ever I want. This frees me from having to 'embed' in my client a piece of the server -- thus there is no longer any 'hard-coupling' between two 'things'.

[We'll skip the fact that SOAP, CORBA, [D]COM[+], and "Java" are a rather orthogonal set of technologies ...]

What is apparently not understood by garoush is that CORBA, DCOM, COM+, Java RMI, do much much more than just simply pass messages from one GAGA to another. [I recommend this great book written specifically for GAGAs for more information on what real (i.e. working) Inter-GAGA Communication Protocols require to function. (Check out the GAGAs on the cover!)] .

Lets just take Java's RMI as an example. What's this with RMI you say? Why didn't they call it Java RPC? I'm glad you asked. See the 'M' in RMI? That's a method, which is a procedure bound to an object. The P in RPC refers to a procedure, which is not necessarily bound to anything. To invoke a method of an object, you first need to get a handle on the object, a remote reference. Any object you say? No. Objects which have been registered with a Registry/Directory Service ( UDDI anyone?) Then you pass the method invocation message to the remote object and a bit of infrastructure on the receiving end maps your method invocation message to an actual method call on the specific object you are invoking. This sub-process of mapping your messages to actual method calls on a specific object uses a messaging protocol which is analogous to what SOAP specifies.

So:

Smoke: SOAP (& XML-RPC) are distributed object technologies! [This goes beyond Smoke and verges on GAGA humor..]

Fact: SOAP is a Simple Xml-based Messaging Protocol (SXMP)

Fact: By the time you have implemented a true Simple Object Access Protocol using a SXMP, you will have something that will look awfully close to RMI. (With the exception that RMI doesn't shuffle needlessly verbose ASCII bits through its system-level plumbing, but your SOAP does.)

In short, by the time you have provided the functionality of an RMI mechanism, such as Java RMI, using SOAP (or any RPC mechanism), you will have accomplished, by the prerequisite functionality of the task at hand, a fairly complex bit of software engineering. Congratulations! (CORBA? Oh boy ...)

In short, using SOAP, we now enable a true 'smart' data-exchange-protocol between two systems such that development is now at the level of "data-exchange" rather than API, SDK, language, etc.

No. More likely, you will realize that having standardized on the data-exchange, you have in effect delegated the complexity of building a distributed object system to the client as opposed to the infrastructure.

Now that is smart. [Good going there Bill!]

[Meanwhile, back on Earth, garoush's friends and would-be rescuers [will] happen upon a long forgotten SOAP Server log file. There, buried among other debug and error messages is the messaging logging the error message the SOAP server sent back to garoush back on planet X. "Ouch" says one of garoush's friends. "I hope he is OK". Now, isn't it just great that XML messages are human readable? (Its too back Servers aren't human -- damn shameful waste of all that human readable information!)]

Smoke: SOAP/XML is a great leap forward!

Fact: Bubble Economies produce Bubble Technologies .

Lets clear the smoke.

If "two" (forget more for a second) "alien-things" happened to agree to use a messaging protocol, such as SOAP, well, right there we would have a minor (but cosmic , considering that "alien-things" are involved) miracle , since apparently they communicated their agreement without a common communication means. (No. Telepathy doesn't count.)

Smoke: XML messaging (SOAP) works miracles!

Fact: "[A]lien-things" first need a common mechanism for reaching consensus regarding communication of information..

So lets say they belong to the Inter-Galactic Alliance of Geeky "Alien-Things" [I-GAGA-T(TM)], governed by the I-GAGA-T's strict policies regarding communication means deployment. [Kinda like the saying "lets all use HTTP"]. Then, our two brave "alien-things", charter members of I-GAGA-T (affectionately known to each other as GAGAs), decide to communicate using SOAP, at which point they have fulfilled "the ONLY requirement when doing client/server" according to their recently hired communication consultant, an Earthling named garoush . [Believe me folks, I am not making this up. A true story from the GAGA archives.]

But have they?

No. One of the GAGAs decides to send a message using SOAP to its newly acquired friend! So the trusty (and somewhat rusty) SOAP client is fired up and the message is sent. And guess what? Promptly comes the standard error reply: "Message received, NOT understood. Ca va?"

Put simply, using SOAP, two or more 'alien-things' can communicate to each other as long as they agree on the SOAP protocol - which is the ONLY requirement when doing client/server using SOAP.

So, put simply, the above is a false statement.

[And this point in the story, we find an agitated and nervous garoush, furiously sending SOAPy messages to Earth: "<help>Me!!</help>" -- Lets hope that back on Earth, garoush's friends have first agreed on the Rescue-Message-Format! (But maybe they didn't, hey garoush? "Just use SOAP" he used to say back on Earth. Well ... Just use SOAP then :) )]

SOAP, and XML-RPC, both provide a means for one GAGA to send messages to another GAGA, even if the two GAGA have discovered each other for the very first time. And this messaging protocol , based on the well-understood [there!] request-reply paradigm, and utilizing a standard XML-based message container , delivers SOAP-compliant XML messages from the sender to the receiver.

So as garoush learned/will-learn [funny thing, this space-time continuum] from his consulting gig to the GAGAs, <help>Me!</help> is not defined. For the content of the message, which delivers information from garoush back to Earth, to be understood by the recipient's), he and his hoped-for-rescuers would have first needed to agree on the format of encoding information in your SOAPy messages.

Sure CORBA, DCOM, COM+, Java, etc. allow you to enable two different components to talk to each other, but those technologies do it in such a way that you must have a 'piece' of the server (called the client) to be delivered and used by the client developer. Thus, to talk with a 'server' you must meet the needs of the 'server' when using CORBA, DCOM, COM+, Java, etc. With SOAP, this is all eliminated. As long as the server publishes its API via the SOAP protocol, I can write my client to talk with the server using what ever I want. This frees me from having to 'embed' in my client a piece of the server -- thus there is no longer any 'hard-coupling' between two 'things'.

[We'll skip the fact that SOAP, CORBA, [D]COM[+], and "Java" are a rather orthogonal set of technologies ...]

What is apparently not understood by garoush is that CORBA, DCOM, COM+, Java RMI, do much much more than just simply pass messages from one GAGA to another. [I recommend this great book written specifically for GAGAs for more information on what real (i.e. working) Inter-GAGA Communication Protocols require to function. (Check out the GAGAs on the cover!)] .

Lets just take Java's RMI as an example. What's this with RMI you say? Why didn't they call it Java RPC? I'm glad you asked. See the 'M' in RMI? That's a method, which is a procedure bound to an object. The P in RPC refers to a procedure, which is not necessarily bound to anything. To invoke a method of an object, you first need to get a handle on the object, a remote reference. Any object you say? No. Objects which have been registered with a Registry/Directory Service ( UDDI anyone?) Then you pass the method invocation message to the remote object and a bit of infrastructure on the receiving end maps your method invocation message to an actual method call on the specific object you are invoking. This sub-process of mapping your messages to actual method calls on a specific object uses a messaging protocol which is analogous to what SOAP specifies.

So:

Smoke: SOAP (& XML-RPC) are distributed object technologies! [This goes beyond Smoke and verges on GAGA humor..]

Fact: SOAP is a Simple Xml-based Messaging Protocol (SXMP)

Fact: By the time you have implemented a true Simple Object Access Protocol using a SXMP, you will have something that will look awfully close to RMI. (With the exception that RMI doesn't shuffle needlessly verbose ASCII bits through its system-level plumbing, but your SOAP does.)

In short, by the time you have provided the functionality of an RMI mechanism, such as Java RMI, using SOAP (or any RPC mechanism), you will have accomplished, by the prerequisite functionality of the task at hand, a fairly complex bit of software engineering. Congratulations! (CORBA? Oh boy ...)

In short, using SOAP, we now enable a true 'smart' data-exchange-protocol between two systems such that development is now at the level of "data-exchange" rather than API, SDK, language, etc.

No. More likely, you will realize that having standardized on the data-exchange, you have in effect delegated the complexity of building a distributed object system to the client as opposed to the infrastructure.

Now that is smart. [Good going there Bill!]

[Meanwhile, back on Earth, garoush's friends and would-be rescuers [will] happen upon a long forgotten SOAP Server log file. There, buried among other debug and error messages is the messaging logging the error message the SOAP server sent back to garoush back on planet X. "Ouch" says one of garoush's friends. "I hope he is OK". Now, isn't it just great that XML messages are human readable? (Its too back Servers aren't human -- damn shameful waste of all that human readable information!)]

Smoke: SOAP/XML is a great leap forward!

Fact: Bubble Economies produce Bubble Technologies .

Lets clear the smoke.

If "two" (forget more for a second) "alien-things" happened to agree to use a messaging protocol, such as SOAP, well, right there we would have a minor (but cosmic , considering that "alien-things" are involved) miracle , since apparently they communicated their agreement without a common communication means. (No. Telepathy doesn't count.)

Smoke: XML messaging (SOAP) works miracles!

Fact: "[A]lien-things" first need a common mechanism for reaching consensus regarding communication of information..

So lets say they belong to the Inter-Galactic Alliance of Geeky "Alien-Things" [I-GAGA-T(TM)], governed by the I-GAGA-T's strict policies regarding communication means deployment. [Kinda like the saying "lets all use HTTP"]. Then, our two brave "alien-things", charter members of I-GAGA-T (affectionately known to each other as GAGAs), decide to communicate using SOAP, at which point they have fulfilled "the ONLY requirement when doing client/server" according to their recently hired communication consultant, an Earthling named garoush . [Believe me folks, I am not making this up. A true story from the GAGA archives.]

But have they?

No. One of the GAGAs decides to send a message using SOAP to its newly acquired friend! So the trusty (and somewhat rusty) SOAP client is fired up and the message is sent. And guess what? Promptly comes the standard error reply: "Message received, NOT understood. Ca va?"

Put simply, using SOAP, two or more 'alien-things' can communicate to each other as long as they agree on the SOAP protocol - which is the ONLY requirement when doing client/server using SOAP.

So, put simply, the above is a false statement.

[And this point in the story, we find an agitated and nervous garoush, furiously sending SOAPy messages to Earth: "<help>Me!!</help>" -- Lets hope that back on Earth, garoush's friends have first agreed on the Rescue-Message-Format! (But maybe they didn't, hey garoush? "Just use SOAP" he used to say back on Earth. Well ... Just use SOAP then :) )]

SOAP, and XML-RPC, both provide a means for one GAGA to send messages to another GAGA, even if the two GAGA have discovered each other for the very first time. And this messaging protocol , based on the well-understood [there!] request-reply paradigm, and utilizing a standard XML-based message container , delivers SOAP-compliant XML messages from the sender to the receiver.

So as garoush learned/will-learn [funny thing, this space-time continuum] from his consulting gig to the GAGAs, <help>Me!</help> is not defined. For the content of the message, which delivers information from garoush back to Earth, to be understood by the recipient's), he and his hoped-for-rescuers would have first needed to agree on the format of encoding information in your SOAPy messages.

Sure CORBA, DCOM, COM+, Java, etc. allow you to enable two different components to talk to each other, but those technologies do it in such a way that you must have a 'piece' of the server (called the client) to be delivered and used by the client developer. Thus, to talk with a 'server' you must meet the needs of the 'server' when using CORBA, DCOM, COM+, Java, etc. With SOAP, this is all eliminated. As long as the server publishes its API via the SOAP protocol, I can write my client to talk with the server using what ever I want. This frees me from having to 'embed' in my client a piece of the server -- thus there is no longer any 'hard-coupling' between two 'things'.

[We'll skip the fact that SOAP, CORBA, [D]COM[+], and "Java" are a rather orthogonal set of technologies ...]

What is apparently not understood by garoush is that CORBA, DCOM, COM+, Java RMI, do much much more than just simply pass messages from one GAGA to another. [I recommend this great book written specifically for GAGAs for more information on what real (i.e. working) Inter-GAGA Communication Protocols require to function. (Check out the GAGAs on the cover!)] .

Lets just take Java's RMI as an example. What's this with RMI you say? Why didn't they call it Java RPC? I'm glad you asked. See the 'M' in RMI? That's a method, which is a procedure bound to an object. The P in RPC refers to a procedure, which is not necessarily bound to anything. To invoke a method of an object, you first need to get a handle on the object, a remote reference. Any object you say? No. Objects which have been registered with a Registry/Directory Service ( UDDI anyone?) Then you pass the method invocation message to the remote object and a bit of infrastructure on the receiving end maps your method invocation message to an actual method call on the specific object you are invoking. This sub-process of mapping your messages to actual method calls on a specific object uses a messaging protocol which is analogous to what SOAP specifies.

So:

Smoke: SOAP (& XML-RPC) are distributed object technologies! [This goes beyond Smoke and verges on GAGA humor..]

Fact: SOAP is a Simple Xml-based Messaging Protocol (SXMP)

Fact: By the time you have implemented a true Simple Object Access Protocol using a SXMP, you will have something that will look awfully close to RMI. (With the exception that RMI doesn't shuffle needlessly verbose ASCII bits through its system-level plumbing, but your SOAP does.)

In short, by the time you have provided the functionality of an RMI mechanism, such as Java RMI, using SOAP (or any RPC mechanism), you will have accomplished, by the prerequisite functionality of the task at hand, a fairly complex bit of software engineering. Congratulations! (CORBA? Oh boy ...)

In short, using SOAP, we now enable a true 'smart' data-exchange-protocol between two systems such that development is now at the level of "data-exchange" rather than API, SDK, language, etc.

No. More likely, you will realize that having standardized on the data-exchange, you have in effect delegated the complexity of building a distributed object system to the client as opposed to the infrastructure.

Now that is smart. [Good going there Bill!]

[Meanwhile, back on Earth, garoush's friends and would-be rescuers [will] happen upon a long forgotten SOAP Server log file. There, buried among other debug and error messages is the messaging logging the error message the SOAP server sent back to garoush back on planet X. "Ouch" says one of garoush's friends. "I hope he is OK". Now, isn't it just great that XML messages are human readable? (Its too back Servers aren't human -- damn shameful waste of all that human readable information!)]

Smoke: SOAP/XML is a great leap forward!

Fact: Bubble Economies produce Bubble Technologies .

Lets clear the smoke.

If "two" (forget more for a second) "alien-things" happened to agree to use a messaging protocol, such as SOAP, well, right there we would have a minor (but cosmic , considering that "alien-things" are involved) miracle , since apparently they communicated their agreement without a common communication means. (No. Telepathy doesn't count.)

Smoke: XML messaging (SOAP) works miracles!

Fact: "[A]lien-things" first need a common mechanism for reaching consensus regarding communication of information..

So lets say they belong to the Inter-Galactic Alliance of Geeky "Alien-Things" [I-GAGA-T(TM)], governed by the I-GAGA-T's strict policies regarding communication means deployment. [Kinda like the saying "lets all use HTTP"]. Then, our two brave "alien-things", charter members of I-GAGA-T (affectionately known to each other as GAGAs), decide to communicate using SOAP, at which point they have fulfilled "the ONLY requirement when doing client/server" according to their recently hired communication consultant, an Earthling named garoush . [Believe me folks, I am not making this up. A true story from the GAGA archives.]

But have they?

No. One of the GAGAs decides to send a message using SOAP to its newly acquired friend! So the trusty (and somewhat rusty) SOAP client is fired up and the message is sent. And guess what? Promptly comes the standard error reply: "Message received, NOT understood. Ca va?"

Put simply, using SOAP, two or more 'alien-things' can communicate to each other as long as they agree on the SOAP protocol - which is the ONLY requirement when doing client/server using SOAP.

So, put simply, the above is a false statement.

[And this point in the story, we find an agitated and nervous garoush, furiously sending SOAPy messages to Earth: "<help>Me!!</help>" -- Lets hope that back on Earth, garoush's friends have first agreed on the Rescue-Message-Format! (But maybe they didn't, hey garoush? "Just use SOAP" he used to say back on Earth. Well ... Just use SOAP then :) )]

SOAP, and XML-RPC, both provide a means for one GAGA to send messages to another GAGA, even if the two GAGA have discovered each other for the very first time. And this messaging protocol , based on the well-understood [there!] request-reply paradigm, and utilizing a standard XML-based message container , delivers SOAP-compliant XML messages from the sender to the receiver.

So as garoush learned/will-learn [funny thing, this space-time continuum] from his consulting gig to the GAGAs, <help>Me!</help> is not defined. For the content of the message, which delivers information from garoush back to Earth, to be understood by the recipient's), he and his hoped-for-rescuers would have first needed to agree on the format of encoding information in your SOAPy messages.

Sure CORBA, DCOM, COM+, Java, etc. allow you to enable two different components to talk to each other, but those technologies do it in such a way that you must have a 'piece' of the server (called the client) to be delivered and used by the client developer. Thus, to talk with a 'server' you must meet the needs of the 'server' when using CORBA, DCOM, COM+, Java, etc. With SOAP, this is all eliminated. As long as the server publishes its API via the SOAP protocol, I can write my client to talk with the server using what ever I want. This frees me from having to 'embed' in my client a piece of the server -- thus there is no longer any 'hard-coupling' between two 'things'.

[We'll skip the fact that SOAP, CORBA, [D]COM[+], and "Java" are a rather orthogonal set of technologies ...]

What is apparently not understood by garoush is that CORBA, DCOM, COM+, Java RMI, do much much more than just simply pass messages from one GAGA to another. [I recommend this great book written specifically for GAGAs for more information on what real (i.e. working) Inter-GAGA Communication Protocols require to function. (Check out the GAGAs on the cover!)] .

Lets just take Java's RMI as an example. What's this with RMI you say? Why didn't they call it Java RPC? I'm glad you asked. See the 'M' in RMI? That's a method, which is a procedure bound to an object. The P in RPC refers to a procedure, which is not necessarily bound to anything. To invoke a method of an object, you first need to get a handle on the object, a remote reference. Any object you say? No. Objects which have been registered with a Registry/Directory Service ( UDDI anyone?) Then you pass the method invocation message to the remote object and a bit of infrastructure on the receiving end maps your method invocation message to an actual method call on the specific object you are invoking. This sub-process of mapping your messages to actual method calls on a specific object uses a messaging protocol which is analogous to what SOAP specifies.

So:

Smoke: SOAP (& XML-RPC) are distributed object technologies! [This goes beyond Smoke and verges on GAGA humor..]

Fact: SOAP is a Simple Xml-based Messaging Protocol (SXMP)

Fact: By the time you have implemented a true Simple Object Access Protocol using a SXMP, you will have something that will look awfully close to RMI. (With the exception that RMI doesn't shuffle needlessly verbose ASCII bits through its system-level plumbing, but your SOAP does.)

In short, by the time you have provided the functionality of an RMI mechanism, such as Java RMI, using SOAP (or any RPC mechanism), you will have accomplished, by the prerequisite functionality of the task at hand, a fairly complex bit of software engineering. Congratulations! (CORBA? Oh boy ...)

In short, using SOAP, we now enable a true 'smart' data-exchange-protocol between two systems such that development is now at the level of "data-exchange" rather than API, SDK, language, etc.

No. More likely, you will realize that having standardized on the data-exchange, you have in effect delegated the complexity of building a distributed object system to the client as opposed to the infrastructure.

Now that is smart. [Good going there Bill!]

[Meanwhile, back on Earth, garoush's friends and would-be rescuers [will] happen upon a long forgotten SOAP Server log file. There, buried among other debug and error messages is the messaging logging the error message the SOAP server sent back to garoush back on planet X. "Ouch" says one of garoush's friends. "I hope he is OK". Now, isn't it just great that XML messages are human readable? (Its too back Servers aren't human -- damn shameful waste of all that human readable information!)]

Smoke: SOAP/XML is a great leap forward!

Fact: Bubble Economies produce Bubble Technologies .

Lets clear the smoke.

If "two" (forget more for a second) "alien-things" happened to agree to use a messaging protocol, such as SOAP, well, right there we would have a minor (but cosmic , considering that "alien-things" are involved) miracle , since apparently they communicated their agreement without a common communication means. (No. Telepathy doesn't count.)

Smoke: XML messaging (SOAP) works miracles!

Fact: "[A]lien-things" first need a common mechanism for reaching consensus regarding communication of information..

So lets say they belong to the Inter-Galactic Alliance of Geeky "Alien-Things" [I-GAGA-T(TM)], governed by the I-GAGA-T's strict policies regarding communication means deployment. [Kinda like the saying "lets all use HTTP"]. Then, our two brave "alien-things", charter members of I-GAGA-T (affectionately known to each other as GAGAs), decide to communicate using SOAP, at which point they have fulfilled "the ONLY requirement when doing client/server" according to their recently hired communication consultant, an Earthling named garoush . [Believe me folks, I am not making this up. A true story from the GAGA archives.]

But have they?

No. One of the GAGAs decides to send a message using SOAP to its newly acquired friend! So the trusty (and somewhat rusty) SOAP client is fired up and the message is sent. And guess what? Promptly comes the standard error reply: "Message received, NOT understood. Ca va?"

Put simply, using SOAP, two or more 'alien-things' can communicate to each other as long as they agree on the SOAP protocol - which is the ONLY requirement when doing client/server using SOAP.

So, put simply, the above is a false statement.

[And this point in the story, we find an agitated and nervous garoush, furiously sending SOAPy messages to Earth: "<help>Me!!</help>" -- Lets hope that back on Earth, garoush's friends have first agreed on the Rescue-Message-Format! (But maybe they didn't, hey garoush? "Just use SOAP" he used to say back on Earth. Well ... Just use SOAP then :) )]

SOAP, and XML-RPC, both provide a means for one GAGA to send messages to another GAGA, even if the two GAGA have discovered each other for the very first time. And this messaging protocol , based on the well-understood [there!] request-reply paradigm, and utilizing a standard XML-based message container , delivers SOAP-compliant XML messages from the sender to the receiver.

So as garoush learned/will-learn [funny thing, this space-time continuum] from his consulting gig to the GAGAs, <help>Me!</help> is not defined. For the content of the message, which delivers information from garoush back to Earth, to be understood by the recipient's), he and his hoped-for-rescuers would have first needed to agree on the format of encoding information in your SOAPy messages.

Sure CORBA, DCOM, COM+, Java, etc. allow you to enable two different components to talk to each other, but those technologies do it in such a way that you must have a 'piece' of the server (called the client) to be delivered and used by the client developer. Thus, to talk with a 'server' you must meet the needs of the 'server' when using CORBA, DCOM, COM+, Java, etc. With SOAP, this is all eliminated. As long as the server publishes its API via the SOAP protocol, I can write my client to talk with the server using what ever I want. This frees me from having to 'embed' in my client a piece of the server -- thus there is no longer any 'hard-coupling' between two 'things'.

[We'll skip the fact that SOAP, CORBA, [D]COM[+], and "Java" are a rather orthogonal set of technologies ...]

What is apparently not understood by garoush is that CORBA, DCOM, COM+, Java RMI, do much much more than just simply pass messages from one GAGA to another. [I recommend this great book written specifically for GAGAs for more information on what real (i.e. working) Inter-GAGA Communication Protocols require to function. (Check out the GAGAs on the cover!)] .

Lets just take Java's RMI as an example. What's this with RMI you say? Why didn't they call it Java RPC? I'm glad you asked. See the 'M' in RMI? That's a method, which is a procedure bound to an object. The P in RPC refers to a procedure, which is not necessarily bound to anything. To invoke a method of an object, you first need to get a handle on the object, a remote reference. Any object you say? No. Objects which have been registered with a Registry/Directory Service ( UDDI anyone?) Then you pass the method invocation message to the remote object and a bit of infrastructure on the receiving end maps your method invocation message to an actual method call on the specific object you are invoking. This sub-process of mapping your messages to actual method calls on a specific object uses a messaging protocol which is analogous to what SOAP specifies.

So:

Smoke: SOAP (& XML-RPC) are distributed object technologies! [This goes beyond Smoke and verges on GAGA humor..]

Fact: SOAP is a Simple Xml-based Messaging Protocol (SXMP)

Fact: By the time you have implemented a true Simple Object Access Protocol using a SXMP, you will have something that will look awfully close to RMI. (With the exception that RMI doesn't shuffle needlessly verbose ASCII bits through its system-level plumbing, but your SOAP does.)

In short, by the time you have provided the functionality of an RMI mechanism, such as Java RMI, using SOAP (or any RPC mechanism), you will have accomplished, by the prerequisite functionality of the task at hand, a fairly complex bit of software engineering. Congratulations! (CORBA? Oh boy ...)

In short, using SOAP, we now enable a true 'smart' data-exchange-protocol between two systems such that development is now at the level of "data-exchange" rather than API, SDK, language, etc.

No. More likely, you will realize that having standardized on the data-exchange, you have in effect delegated the complexity of building a distributed object system to the client as opposed to the infrastructure.

Now that is smart. [Good going there Bill!]

[Meanwhile, back on Earth, garoush's friends and would-be rescuers [will] happen upon a long forgotten SOAP Server log file. There, buried among other debug and error messages is the messaging logging the error message the SOAP server sent back to garoush back on planet X. "Ouch" says one of garoush's friends. "I hope he is OK". Now, isn't it just great that XML messages are human readable? (Its too back Servers aren't human -- damn shameful waste of all that human readable information!)]

Smoke: SOAP/XML is a great leap forward!

Fact: Bubble Economies produce Bubble Technologies .

Lets clear the smoke.

If "two" (forget more for a second) "alien-things" happened to agree to use a messaging protocol, such as SOAP, well, right there we would have a minor (but cosmic , considering that "alien-things" are involved) miracle , since apparently they communicated their agreement without a common communication means. (No. Telepathy doesn't count.)

Smoke: XML messaging (SOAP) works miracles!

Fact: "[A]lien-things" first need a common mechanism for reaching consensus regarding communication of information..

So lets say they belong to the Inter-Galactic Alliance of Geeky "Alien-Things" [I-GAGA-T(TM)], governed by the I-GAGA-T's strict policies regarding communication means deployment. [Kinda like the saying "lets all use HTTP"]. Then, our two brave "alien-things", charter members of I-GAGA-T (affectionately known to each other as GAGAs), decide to communicate using SOAP, at which point they have fulfilled "the ONLY requirement when doing client/server" according to their recently hired communication consultant, an Earthling named garoush . [Believe me folks, I am not making this up. A true story from the GAGA archives.]

But have they?

No. One of the GAGAs decides to send a message using SOAP to its newly acquired friend! So the trusty (and somewhat rusty) SOAP client is fired up and the message is sent. And guess what? Promptly comes the standard error reply: "Message received, NOT understood. Ca va?"

Put simply, using SOAP, two or more 'alien-things' can communicate to each other as long as they agree on the SOAP protocol - which is the ONLY requirement when doing client/server using SOAP.

So, put simply, the above is a false statement.

[And this point in the story, we find an agitated and nervous garoush, furiously sending SOAPy messages to Earth: "<help>Me!!</help>" -- Lets hope that back on Earth, garoush's friends have first agreed on the Rescue-Message-Format! (But maybe they didn't, hey garoush? "Just use SOAP" he used to say back on Earth. Well ... Just use SOAP then :) )]

SOAP, and XML-RPC, both provide a means for one GAGA to send messages to another GAGA, even if the two GAGA have discovered each other for the very first time. And this messaging protocol , based on the well-understood [there!] request-reply paradigm, and utilizing a standard XML-based message container , delivers SOAP-compliant XML messages from the sender to the receiver.

So as garoush learned/will-learn [funny thing, this space-time continuum] from his consulting gig to the GAGAs, <help>Me!</help> is not defined. For the content of the message, which delivers information from garoush back to Earth, to be understood by the recipient's), he and his hoped-for-rescuers would have first needed to agree on the format of encoding information in your SOAPy messages.

Sure CORBA, DCOM, COM+, Java, etc. allow you to enable two different components to talk to each other, but those technologies do it in such a way that you must have a 'piece' of the server (called the client) to be delivered and used by the client developer. Thus, to talk with a 'server' you must meet the needs of the 'server' when using CORBA, DCOM, COM+, Java, etc. With SOAP, this is all eliminated. As long as the server publishes its API via the SOAP protocol, I can write my client to talk with the server using what ever I want. This frees me from having to 'embed' in my client a piece of the server -- thus there is no longer any 'hard-coupling' between two 'things'.

[We'll skip the fact that SOAP, CORBA, [D]COM[+], and "Java" are a rather orthogonal set of technologies ...]

What is apparently not understood by garoush is that CORBA, DCOM, COM+, Java RMI, do much much more than just simply pass messages from one GAGA to another. [I recommend this great book written specifically for GAGAs for more information on what real (i.e. working) Inter-GAGA Communication Protocols require to function. (Check out the GAGAs on the cover!)] .

Lets just take Java's RMI as an example. What's this with RMI you say? Why didn't they call it Java RPC? I'm glad you asked. See the 'M' in RMI? That's a method, which is a procedure bound to an object. The P in RPC refers to a procedure, which is not necessarily bound to anything. To invoke a method of an object, you first need to get a handle on the object, a remote reference. Any object you say? No. Objects which have been registered with a Registry/Directory Service ( UDDI anyone?) Then you pass the method invocation message to the remote object and a bit of infrastructure on the receiving end maps your method invocation message to an actual method call on the specific object you are invoking. This sub-process of mapping your messages to actual method calls on a specific object uses a messaging protocol which is analogous to what SOAP specifies.

So:

Smoke: SOAP (& XML-RPC) are distributed object technologies! [This goes beyond Smoke and verges on GAGA humor..]

Fact: SOAP is a Simple Xml-based Messaging Protocol (SXMP)

Fact: By the time you have implemented a true Simple Object Access Protocol using a SXMP, you will have something that will look awfully close to RMI. (With the exception that RMI doesn't shuffle needlessly verbose ASCII bits through its system-level plumbing, but your SOAP does.)

In short, by the time you have provided the functionality of an RMI mechanism, such as Java RMI, using SOAP (or any RPC mechanism), you will have accomplished, by the prerequisite functionality of the task at hand, a fairly complex bit of software engineering. Congratulations! (CORBA? Oh boy ...)

In short, using SOAP, we now enable a true 'smart' data-exchange-protocol between two systems such that development is now at the level of "data-exchange" rather than API, SDK, language, etc.

No. More likely, you will realize that having standardized on the data-exchange, you have in effect delegated the complexity of building a distributed object system to the client as opposed to the infrastructure.

Now that is smart. [Good going there Bill!]

[Meanwhile, back on Earth, garoush's friends and would-be rescuers [will] happen upon a long forgotten SOAP Server log file. There, buried among other debug and error messages is the messaging logging the error message the SOAP server sent back to garoush back on planet X. "Ouch" says one of garoush's friends. "I hope he is OK". Now, isn't it just great that XML messages are human readable? (Its too back Servers aren't human -- damn shameful waste of all that human readable information!)]

Smoke: SOAP/XML is a great leap forward!

Fact: Bubble Economies produce Bubble Technologies .

Lets clear the smoke.

If "two" (forget more for a second) "alien-things" happened to agree to use a messaging protocol, such as SOAP, well, right there we would have a minor (but cosmic , considering that "alien-things" are involved) miracle , since apparently they communicated their agreement without a common communication means. (No. Telepathy doesn't count.)

Smoke: XML messaging (SOAP) works miracles!

Fact: "[A]lien-things" first need a common mechanism for reaching consensus regarding communication of information..

So lets say they belong to the Inter-Galactic Alliance of Geeky "Alien-Things" [I-GAGA-T(TM)], governed by the I-GAGA-T's strict policies regarding communication means deployment. [Kinda like the saying "lets all use HTTP"]. Then, our two brave "alien-things", charter members of I-GAGA-T (affectionately known to each other as GAGAs), decide to communicate using SOAP, at which point they have fulfilled "the ONLY requirement when doing client/server" according to their recently hired communication consultant, an Earthling named garoush . [Believe me folks, I am not making this up. A true story from the GAGA archives.]

But have they?

No. One of the GAGAs decides to send a message using SOAP to its newly acquired friend! So the trusty (and somewhat rusty) SOAP client is fired up and the message is sent. And guess what? Promptly comes the standard error reply: "Message received, NOT understood. Ca va?"

Put simply, using SOAP, two or more 'alien-things' can communicate to each other as long as they agree on the SOAP protocol - which is the ONLY requirement when doing client/server using SOAP.

So, put simply, the above is a false statement.

[And this point in the story, we find an agitated and nervous garoush, furiously sending SOAPy messages to Earth: "<help>Me!!</help>" -- Lets hope that back on Earth, garoush's friends have first agreed on the Rescue-Message-Format! (But maybe they didn't, hey garoush? "Just use SOAP" he used to say back on Earth. Well ... Just use SOAP then :) )]

SOAP, and XML-RPC, both provide a means for one GAGA to send messages to another GAGA, even if the two GAGA have discovered each other for the very first time. And this messaging protocol , based on the well-understood [there!] request-reply paradigm, and utilizing a standard XML-based message container , delivers SOAP-compliant XML messages from the sender to the receiver.

So as garoush learned/will-learn [funny thing, this space-time continuum] from his consulting gig to the GAGAs, <help>Me!</help> is not defined. For the content of the message, which delivers information from garoush back to Earth, to be understood by the recipient's), he and his hoped-for-rescuers would have first needed to agree on the format of encoding information in your SOAPy messages.

Sure CORBA, DCOM, COM+, Java, etc. allow you to enable two different components to talk to each other, but those technologies do it in such a way that you must have a 'piece' of the server (called the client) to be delivered and used by the client developer. Thus, to talk with a 'server' you must meet the needs of the 'server' when using CORBA, DCOM, COM+, Java, etc. With SOAP, this is all eliminated. As long as the server publishes its API via the SOAP protocol, I can write my client to talk with the server using what ever I want. This frees me from having to 'embed' in my client a piece of the server -- thus there is no longer any 'hard-coupling' between two 'things'.

[We'll skip the fact that SOAP, CORBA, [D]COM[+], and "Java" are a rather orthogonal set of technologies ...]

What is apparently not understood by garoush is that CORBA, DCOM, COM+, Java RMI, do much much more than just simply pass messages from one GAGA to another. [I recommend this great book written specifically for GAGAs for more information on what real (i.e. working) Inter-GAGA Communication Protocols require to function. (Check out the GAGAs on the cover!)] .

Lets just take Java's RMI as an example. What's this with RMI you say? Why didn't they call it Java RPC? I'm glad you asked. See the 'M' in RMI? That's a method, which is a procedure bound to an object. The P in RPC refers to a procedure, which is not necessarily bound to anything. To invoke a method of an object, you first need to get a handle on the object, a remote reference. Any object you say? No. Objects which have been registered with a Registry/Directory Service ( UDDI anyone?) Then you pass the method invocation message to the remote object and a bit of infrastructure on the receiving end maps your method invocation message to an actual method call on the specific object you are invoking. This sub-process of mapping your messages to actual method calls on a specific object uses a messaging protocol which is analogous to what SOAP specifies.

So:

Smoke: SOAP (& XML-RPC) are distributed object technologies! [This goes beyond Smoke and verges on GAGA humor..]

Fact: SOAP is a Simple Xml-based Messaging Protocol (SXMP)

Fact: By the time you have implemented a true Simple Object Access Protocol using a SXMP, you will have something that will look awfully close to RMI. (With the exception that RMI doesn't shuffle needlessly verbose ASCII bits through its system-level plumbing, but your SOAP does.)

In short, by the time you have provided the functionality of an RMI mechanism, such as Java RMI, using SOAP (or any RPC mechanism), you will have accomplished, by the prerequisite functionality of the task at hand, a fairly complex bit of software engineering. Congratulations! (CORBA? Oh boy ...)

In short, using SOAP, we now enable a true 'smart' data-exchange-protocol between two systems such that development is now at the level of "data-exchange" rather than API, SDK, language, etc.

No. More likely, you will realize that having standardized on the data-exchange, you have in effect delegated the complexity of building a distributed object system to the client as opposed to the infrastructure.

Now that is smart. [Good going there Bill!]

[Meanwhile, back on Earth, garoush's friends and would-be rescuers [will] happen upon a long forgotten SOAP Server log file. There, buried among other debug and error messages is the messaging logging the error message the SOAP server sent back to garoush back on planet X. "Ouch" says one of garoush's friends. "I hope he is OK". Now, isn't it just great that XML messages are human readable? (Its too back Servers aren't human -- damn shameful waste of all that human readable information!)]

Smoke: SOAP/XML is a great leap forward!

Fact: Bubble Economies produce Bubble Technologies .

> Well ain't that just fascinating. Jon Bosak of Sun created SOAP?
> Funny, I don't see his name on the credits.

Ah, I see you have reading comprehension problems. Perhaps you might try reading SoftwareJanitor's post slowly and carefully. Especially the part that says "creating XML". Then go and read this. Pay careful attention to the part that says:

• Jon Bosak, Sun (Chair)

> I rest my case, you don't know what you are talking about.

The same could be said for you.

Put simply, using SOAP, two or more 'alien-things' can communicate to each other as long as they agree on the SOAP protocol - which is the ONLY requirement when doing client/server using SOAP.

Sure CORBA, DCOM, COM+, Java, etc. allow you to enable two different components to talk to each other,

SOAP isn't an RPC/DO mechanism comparable to CORBA, DCOM, or RMI because SOAP doesn't specify how to encode many common datatypes found in programming languages. It doesn't even tell you how to encode arbitrary strings.

So, it's hard to say what SOAP is. It's not a mechanism for exchanging arbitrary XML documents (and you can do that much more easily via HTTP anyway). And it's not a mechanism for implementing even the simplest forms of RPC involving real programming languages. It's something that looks like an RPC mechanism but doesn't really deliver.

What it really is is whatever Microsoft does and because the spec is so incomplete, you can't reliably interoperate with it. What you can do is reverse engineer a little more easily. Let's be thankful for little favors, but let's not grow overly enthusiastic.

With SOAP, this is all eliminated. As long as the server publishes its API via the SOAP protocol, I can write my client to talk with the server using what ever I want. This frees me from having to 'embed' in my client a piece of the server -- thus there is no longer any 'hard-coupling' between two 'things'.

This stuff isn't new at all: people had dynamically typed remote interfaces and service descriptions for years. CORBA/DCOM/RMI actually represented a step backwards when they came out.

Dynamically typed remote interfaces and service descriptions are nice and have all sorts of benefits, but they don't eliminate coupling.

In short, using SOAP, we now enable a true 'smart' data-exchange-protocol between two systems such that development is now at the level of "data-exchange" rather than API, SDK, language, etc.

Smart data exchange would require actual smarts: rules, constraints, inferences. There is nothing in the SOAP spec or implementations that supports that. It's extremely naive to assume that those problems will get magically solved merely by using some complicated XML scheme for describing data and services.

The XML community is roughly where the Lisp community was in the 1960's: they are awed by the power and convenience of a universal syntax and dynamic type system and they haven't woken up to the fact that the problems themselves are hard and aren't solved just by having convenient, powerful data types.

Do you really think that, among the other lies and half-truths in your post, that the W3C has specifications for graphics primitives like drawing a line?

I assume you've never heard of SVG, the W3C's "language for describing two-dimensional graphics in XML."

from Miscro$oft (re SOAP 1.0):
"SOAP doesn't care what operating system, programming language, or object model is being used on either the server side or the client side: it is utterly agnostic, except that it needs HTTP as a transport." ( emphasis is mine )

and from W3C( re SOAP 1.1):
"SOAP can potentially be used in combination with a variety of other protocols"