Re: FW: LC Comments: Web Method Feature

"Champion, Mike" wrote:
> 
>...
> 
> There's a lot about REST that I find illuminating, but this "thou shalt
> treat HTTP as the highest level application of The Web" commandment is
> unpersuasive to me, and apparently many others.  It's The Right Thing for
> one technology generation's top level to be the next generation's
> infrastructure.

I think we all agree that HTTP should be the basis for new technologies.
The question is whether they are *new layers* or *new extensions*.

Here's an analogy that might be useful.

TCP is to HTTP as XML is to XHTML. XHTML is layered on top of XML and
XML makes almost no semantic demands on XHTML at all. XHTML can use an
element like <title> to represent something that is "logically" an
attribute and nobody complains. XHTML could use an attribute "date" to
represent something that "logically" has sub-structure and if anyone
complains it is because they are making life somewhat more difficult for
developers. But the XML standard *does not say* that you should use
attributes for "metadata-like things" and elements for "content-like
things". It makes almost no semantic demands on the vocabulary at all.
You would have to work pretty hard to violate the "semantics" of the XML
specification. All you could do, really, is break the *syntax* -- be
not-well-formed. Similarly, applications running on top of TCP have very
few semantic responsibilities. Both XML and TCP are designed to say: "do
what you want, just obey the syntactic rules of the specification."

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". That would destroy interoperability with XHTML processors
in a very dangerous way. The documents would be valid XHTML (according
to validating parsers) but meaningless!

You are supposed to extend XHTML with new elements, and you are supposed
to "subclass" P with "big paragraph" or "important paragraph" or
"disputed paragraph" but you should never state that in "in my variant
of XHTML, two P elements in a row means 'table'" Once you've done that,
it is no longer a variant of XHTML. It is a semantically incompatible
language and interoperability will suffer. Browsers can display it (if
it is valid XHTML) but they are displaying gibberish.

Imagine a future scenario where firewalls filter out all vocabularies
except known ones like XHTML. Someone comes along and says: "We really
need to route arbitrary new hypertext vocabularies through firewalls.
Here's what we'll do. We'll write in NewML and 'serialize' down to HTML.
It won't be semantically meaningful HTML, because we'll use all of the
element types to mean what we want them to mean, and 'deserialize' back
to NewML on the other side. No, even better: we'll make a meta-markup
language and every man woman and child can invent their own new
hypertext markup languages that serialize to and deserialize from HTML."

Now if somebody proposed that, I would have the following responses:

 1. If you needed more features in HTML, did you approach the working
group to add them? Having an incompatible bifurcation doesn't seem
productive. Maybe we could all benefit from your new features?

 2. If the working group turned you down, did you consider using the
existing, documented extension mechanisms? Millions of people have used
them with success. How did they fail you?

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

 4. Anyhow, why do we even need a framework for building hypertext
markup languages? HTML is an extensible hypertext markup language which
demonstrably satisfies most if not all distributed hypertext
presentation needs. When there are a hundred or a thousand markup
language variants, will interoperability be better or worse?

My point is just to clarify why the relationship between SOAP and HTTP
is very different than the relationship between HTTP and TCP or TCP and
IP. HTTP is "top dog" because it defines the baseline semantics for
anything that builds on it, just as XHTML (or RSS or DocBook or...)
does.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/

Received on Friday, 5 July 2002 21:09:01 UTC