RE: FW: LC Comments: Web Method Feature

> -----Original Message-----
> From: Paul Prescod [mailto:paul@prescod.net]
> Sent: Friday, July 05, 2002 9:08 PM
> To: Champion, Mike; 'xml-dist-app@w3.org'
> Subject: Re: FW: LC Comments: Web Method Feature
> 
> 
 
> 
> Now let's go up a step. XHTML is an XML application (in the old "SGML
> application sense). HTTP is an application protocol. They *do* make
> semantic demands on things building on top of them. In other 
> words, you
> MUST extend, not layer, on them. "P" means "paragraph" in XHTML. There
> should never, ever, be a "layer" that adds another semantic on P like
> "parachute". 

OK, I understand the logic better, if not the premise that HTTP is an
"application protocol."  For better or worse, and irrespective of the
intentions of Roy Fielding and Tim Berners-Lee, HTTP has become sortof a
"Network Virtual Terminal" for all sorts of higher-level development.

Hmm, I guess in your analogy this is very much like the way Flash "tunnels"
HTML to deliver its proprietary content to a browser plugin.  I guess I
understand your annoyance about HTTP tunneling better with this analogy in
mind; the standards purist in me is apalled by this situation (although the
pragmatist in me acknowledges that it is a whole lot easier to write a Flash
script that works across 95% of deployed browsers than it is to write
standard Javascript / DOM / XHTML that is equally portable).

>  3. Why do you have to piggy-back on HTML? Just because HTML slips
> through firewalls and is popular? Surely your new markup 
> language could
> have achieved popularity of its own accord on the open market without
> pretending to be HTML. Why not build on XML (TCP, in our analogy).

 It understands URIs (unlike TCP),it's easy to map URIs that the client
generates onto CGI/servlet/etc programs on the server, it exploits a a whole
lot of expensively acquired Web infrastructure that understands URIs,
cacheing, session maintenance, etc., and there are simple APIs in every
programming language to work with it with no heavy lifting required.  In
short, it makes tunneling so easy and attractive, it's hard to resist!

I'm afraid I still don't see a *pragmatic* argument against treating HTTP as
a transport protocol as well as an application protocol, given the world's
multibillion dollar investment in HTTP infrastructure, tools, and knowledge
over the last decade.

Received on Saturday, 6 July 2002 10:37:15 UTC