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?
 Bill de hÓra wrote: > Interesting thread, but I don't fully understand the substance of the > argument: Sorry for not being clear. I'll try to clarify my thoughts. > [[ > (1) A browser blindly displays the HTML on a screen, i.e., there is no > semantic processing of the data. > (2) A human does the semantic processing of what's displayed on the > screen. ]] > > I don't know what semantic processing is (it sounds by definition, > something that humans do). I simply meant that a browser doesn't understand the data, it simply understands how to display the data. Semantic processing can be incorportated into machines. For example, a cellphone application can semantically process XML documents conforming to the cellphone vocabulary. > But those who think browsers don't do > /significant/ processing should consider what implementing > HTML+Stylesheet rendering might involve, compared to say, stuffing an > update into a database. Yes, browsers certainly do a lot of complicated processing, all related to display, not to actually dealing with the data. > [[ > In the case of machine processing of HTML then HTML-REST is on the > order of N^2, i.e., each machine must have n customized programs to > process the n HTML web sites. ]] > > Can you restate this? I'm probably not semantically processing that > statement properly. What does 'process the n HTML web sites' mean to you > here? I mean "screen scraping" a Web page. Processing a screen scrape requires custom coding. > [[ > I therefore conclude that XML-REST is no more scalable than SOAP. ]] > > I could only conclude from your argument that XML-REST is no more > scalable than HTML-REST. And you didn't mention SOAP until then. Yes, I was starting out with the assumption that SOAP is on the order n^2. Sorry for not stating this upfront. > I think you're saying that XML processing is no more scalable than HTML > screen scraping; that has something to do with humans doing a lot of the > interpretive donkey work and the fact that the receiver will have to > have some code to munge the incoming XML from a site. Yes, that's it. Processing arbitrary XML documents entails lots of custom code - one program per different kind of XML document. > But your line of > argument isn't gelling. Perhaps that's because I don't understand what > you mean by 'custom code' and there's more than one meaning of 'process' > in there. Does this help? Walter Perry doesn't like my argument either. I need to digest his comments. > Also, > > 1) the level of work required to programmatically scrape HTML web sites > versus programmatically process XML ones needs to be factored in, > semantics aside, them's apples and oranges; My point was only that processing arbitrary XML documents requires custom code (i.e., is non-scalable) just as processing screen scrapes is non-scalable. > 2) the assumption that XML-REST data won't promptly end up in front of a > human and thus isn't like REST-HTML data is questionable, a lot of this > stuff will be delivered into devices as a flexible replacement for HTML; Yes, there may be some XML that ends up in front of a human. > 3) you're assuming n modules will be required to process n web sites; is > that a reasonable assumption? (consider this as a data point; we haven't > written n servers to build n web sites); My point was simply that if my machine has to process n different XML documents then it will need n different programs. > 4) we're more likely to see n processors where that n are specializing > in a task (see Sean McGrath's material on XPipe or the Pipeline spec, Yes, I have seen Sean's stuff. Most cool. In summary, the argument that I was making is that using REST helps reduce the number of access methods (i.e., accessing is scalable), but the "processing" of n arbitrary XML documents is non-scalable. /Roger 
|
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
|
|||||||||
