[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
language
> 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:
http://www-106.ibm.com/developerworks/xml/library/x-matters15.html?open&l=81
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
