Hello Horst, thanks again for the very careful observation. I can remember last time when someone mentioned a HIS project on this list, you also immediately pointed out the database aspect. We highly value your expertise on this.
On Thursday 29 April 2004 22:06, Horst Herb wrote: > Initially I was thrilled by HXP. Pretty much the suggestion I was pushing > locally for the past two years, and a delight to see somebody actually > organizing it. A simple and straightforward solution, very easy to > implement, close to zero initial barriers, but immensely expandable. Yes, you are right on this. May I add, this is probably the so-called "large white wall" > However, after reading a few details, I was dismayed: Why, oh why, > perpetuate the deficiencies of flat table data storage into the 21st > century??? I refuse to believe that you get discouraged too easily, Horst. My high respect of you just simply preventa me from believing it. It doesn't fit your intellectual profile, so I assume that you are just joking. We want to pattern the hxp "talk" after common human conversation habits (of course in a subjective way). If we take english for example, we will surely wonder why we are still using it today (when was english actually invented?). > While XML-RPC caters for complex dynamic data types such as maps > (dictionaries) etc., how comes that we still would find "telephone1" and > "telephone2" ???? Breaking all rules of good database design, and that > includes designs of persistent objects or access to such. Yes, this is probably the so-called "that tiny spot in the middle" of the "large white wall". These are current proposals and as such are bound to be accepted or discarded. But I say "probably" because the final decision to accept or discard proposals (the proposals may come from you) will be based on the proven actual usefulness or uselessness. For this purpose we need to rigorously test procedures at least in demo applications (ideally in many applications with different design philosophies). If you remember the part on the website about proposing: "nobody is allowed to discriminate other people's proposals". So making a counter-proposal does not automatically defeat the ones being countered. This protects you, me, and all of our intellectual efforts during the proposals phase. Lets say, Horst proposed something, then later on Dave countered it, Horst's proposal will not be summarily dropped. But instead the two will be given the chance to prove their proposals' usefulness (or uselessness). In this connection, it is important that Horst and Dave create demo applications that support their proposals. These demos should be accessible to the largest number of potential users possible (online demo is the best for this purpose). Allow me to summarize: a) Make a proposal in a formal way. Make a pdf document and we will publish it alongside the other proposals. b) Create a demo application supporting the usefulness of your proposal (preferably online demo) c) Instruct us how to use your demo. Anybody is allowed to do anything to "market" his proposals (his ideas) effectively to all of us. But hitting-below-the-belt and discrimination are mortal sins (you will burn in hell :-) ). Now to the question of how can we find the better proposal: well, when a large number of people are testing, the "best practice" will become obvious very easily. And note: "complex and politically correct" does not guarantee it to be the best on practical grounds. Let us democratize protocol developments and let the people decide. Respectfully, elpidio
