Altova Mailing List Archives
>xml-dev Archive Home
>Thread Prev -
>Thread Next - Re: [xml-dev] Hook Stuff Together
Hook Stuff Together
To: 'Joshua Allen' <joshuaa@---------.--->, xml-dev@-----.---.---
Date: 2/14/2002 1:19:00 AM
HST. I like that. I still find it hard to believe that all the complexity of SOAP+WSDL+UDDI (or pick any other acronyms from the list ) is a net benefit. Or a Net benefit. Standards bodies have an unwholesome (and largely unavoidable, though there are exceptions) dynamic towards complexity. All I want to do is hook my stuff together. So, what can we do to get those calling the shots in Web Services standards to: 1. Define a layered system, where the simple cases really are simple 2. Defend the complexity they introduce; explain the phenomenal benefits that more than offset the complexity 3. Work with vendors to produce useful tools for "hooking stuff together" with XML (including "low-tech" methods like XMLchucker or XMLbaton) I don't even care if this comes out of the W3C or the WSIO. Developers need this far worse than another 200 page spec. .micah  http://www.xml.com/pub/a/2002/01/09/soap.html -----Original Message----- From: Joshua Allen [mailto:joshuaa@m...] Sent: Tuesday, February 12, 2002 10:57 AM To: Micah Dubinko; xml-dev@l... Subject: RE: [xml-dev] Principle of Sustainable Complexity > 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?