Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Is XML-REST more scalable than SOAP?
 "Roger L. Costello" wrote: > > I am just ramping up on REST. Please forgive me if my > questions/comments are naive. Roger, detailed discussion should be redirected to the rest-discuss list because people on xml-dev are tired of the repitition that arises from teaching REST to new people as they become interested in it. >... > Now consider the case where web sites serve up XML not HTML (I shall > refer to this as XML-REST). Suppose that the XML is programmatically > processed. The HTTP methods (GET, POST, PUT, etc) provide a nice set of > **access methods** for getting and putting the XML data. Thus, > **accessibility** is scalable as it is on the order of linear. However, > **processing** the XML data still needs customized code (just like > machine processing of HTML requires custom code). I therefore conclude > that XML-REST is no more scalable than SOAP. Yes, this is an important insight. But the linear factor is also important. I believe that it is much easier to standardize XML vocabularies within and between industries than it is to share APIs or messaging interfaces or whatever you want to call them. HTML is merely an extreme example of this. The widespread success of RSS is a second example. (might be interesting to try to understand why RSS is so much more popular on the "public Internet" than is XMLNews...) Obviously "chemical ML" is going to be much less widespread than HTML but I have much more hope that Bayer and 3M would share "chemical ML" than that they would agree on a wire-protocol for describing chemicals. There are a variety of reasons but one reason is that agreeing on a wire-protocol is much closer to agreeing on a *business model* than is agreeing on an XML vocabulary. >... > > How can we make XML-REST scalable? One solution would be to require > every web site to serve up the same type of XML documents, i.e., have a > universal Schema that all XML documents conform to. Obviously this is > not a very attractive solution. The other solution is to have web sites > serve up documents whose meaning can be dynamically "discovered". I > believe that RDF is the only XML technology that enables dynamic > understanding of content. Thus, the cornerstone for a scalable, > machine-processable web services architecture is: > > 1. The HTTP access methods - GET, POST, PUT, etc > 2. A dynamically understandable vocabulary, such as RDF. Yes, this is the approach Mark Baker takes. As I am not (yet?) an RDF "believer" I see it more as a spectrum: as we understand problem domains more and more, we migrate more and more stuff from "the code" into declarative formats that describe the data. RDF fans think that RDF is the declarative "uber-format". We'll see. Maybe. If they are wrong, I still expect dozens of declarative languages like XML Query, XSLT etc. to mature into powerful tools for bootstrapping understanding of a vocabulary. (consider for example an XSLT associated with one industry standard purchase order vocabulary that translates it into another PO vocabulary on demand -- easy to model in an industry-neutral way with URIs and XML). One reason I argue against the "standard web services" model because it moves the very first bit of the problem from the domain of declarations into the domain of code. I.e. to even get the data you need to write code. That's a serious impediment to further exploration down the declarative path. If XML Query turns out to be extremely wonderful and powerful, this fork in the road should come into even greater focus. Paul Prescod 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
