RE: [xml-dev] Principle of Sustainable Complexity

["Joshua Allen" <joshuaa@microsoft.com>]

> Also with interest I observed Simon's thoughts on an 'XMLchucker'
> protocol--a simple send with (at most) a checksum back. I don't doubt
that
> such a straightforward protocol is already in use today, though it's

Yeah, there are plenty of ways to do this today.  I still like DIME and
WS-Routing, because they anticipate a lot of problems that you run into
if you aim at an endpoint that doesn't have a direct TCP connection for
you (now we have proxies and NAT and other stuff all over the net, so
just "chucking" some XML to an endpoint in a totally generic fashion is
not so trivial anymore).

> file in a well-known file system location; process B reads, handles,
and
> deletes the file. Call it XMLbaton.]

Good point; this is very common and useful.  Both of these get at what
Pat Helland calls "HST", or "Hook the Stuff Together".  XML is great for
low-tech HST, and often all of the complication atop miss that point.

> There isn't a rich set of technical writings behind the simple
concepts
> like XMLchucker or XMLbaton. For one thing, the concepts are so simple


Again, a good point.  It seems like everyone just rolls their own
implementations of XMLChucker and XMLBaton without necessarily having a
lot of knowledge of the best practices that other people are using.  I
think that this sort of file-based HST in the Unix world evolved
splendidly with tools like grep, cut, etc. mixed with various network
copy mechanisms like FTP or NFS.  I think that an actual
*implementation* of an XMLChucker or XMLBaton would exist more at the
level of something like GNU wget (which reminds me a lot of robocopy,
which many people use to chuck around XML batons).  Having a set of
widely used (and no cost) tools for reliable copying, detection of files
being dropped in a directory, etc. would probably be quite helpful,
although I bet that Perl and things like wget would be sufficient.  In
addition to the tools for chucking around XML batons in HST work, I
think there is another big gap that HST people run into, which is that
most of the existing HST tools for Unix are based on text files that are
delimited by LF.  Things like grep, cut, and wc are workhorses of HST,
but totally inapplicable to XML.  A set of similar command-line tools
that operate on XPath instead of LF would be a huge help in encouraging
adoption of XML, I think.  I am aware that PaulT, Simon, and maybe some
others have toyed with these ideas, but I still can't download my
"mks-tools for XML".  What gives?

smime.p7s