OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Is XML-REST more scalable than SOAP?

[ Lists Home | Date Index | Thread Index ]

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

> 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.



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS