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