Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: XML / dialects

From: jason:cunliffe:verizon at: 7-Jan-2002 3:38

> I am currently reading the book about XML, SOAP and MS Bizztalk server. > BizTalk app framework seems to be open standard, and there are examples in > the book of how to create one, in some language called OmniMark. Does > anyone use that language? According to book author, it is the best
> he saw for streamed data manipulation on web. Maybe he just doesn't know > about Rebol yet :-)
hmm.. You might appreciate the good series of articles by David Mertz. His focus example are usually in Python, but he has a keen and witty mind and not afraid to think for himself. The latest is about XML-RPC: 0,t=grx,p=rpc <quote> XML-RPC is a remote function invocation protocol with a great virtue: It is worse than all of its competitors. Compared to Java RMI or CORBA or COM, XML-RPC is impoverished in the type of data it can transmit and obese in its message size. XML-RPC abuses the HTTP protocol to circumvent firewalls that exist for good reasons, and as a consequence transmits messages lacking statefulness and incurs channel bottlenecks. Compared to SOAP, XML-RPC lacks both important security mechanisms and a robust object model. As a data representation, XML-RPC is slow, cumbersome, and incomplete compared to native programming language mechanisms like Java's serialize, Python's pickle, Perl's Data::Dumper, or similar modules for Ruby, Lisp, PHP, and many other languages. In other words, XML-RPC is the perfect embodiment of Richard Gabriel's worse-is-better philosophy of software design (see Resources). I can hardly write more glowingly on XML-RPC than I did in the previous paragraph, and I think the protocol is a perfect match for a huge variety of tasks. To understand why, it's worth quoting the tenets of Gabriel's "worse-is-better" philosophy: Simplicity: The design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design. Correctness: The design must be correct in all observable aspects. It is slightly better to be simple than correct. Consistency: The design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency. Completeness: The design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface. </quote> enjoy ./Jason