Re: FW: LC Comments: Web Method Feature

Glen Daniels wrote:
> 
>...
> 
> You add a "layer" above XHTML because you want to provide a meta-markup
> language to allow for a common set of tools and technologies to be built
> which can operate on the "meta-markup" despite the fact that sometimes
> it might serialize to XHTML and other times it might serialize to
> GIF and other times to PDF.  Perhaps you have a "<section>" tag which
> resolves to either a "<p>" in XHTML, or a 15-pixel space in a GIF, or
> an equivalent (sorry, I don't know PDF internals at all :)) in PDF.

You haven't quite got to the heart of the analogy. I'm not against
having a higher level markup language that can generate HTML (or a
meta-protocol that can run on top of HTTP). I'm against having a higher
level markup language *use HTML tags to mean something other than HTML
does*. That's the layering. If I generate HTML from DocBook I'm not
layering. I'm not even extending. After all, the only thing that goes
across the wire is syntactically and semantically valid HTML. It's just
as much HTML as if I had written it by hand. If the same is true for all
SOAP over HTTP then nobody will complain about SOAP over HTTP. But it
isn't just about respecting HTTP's syntax, there is also a requirement
to support HTTP semantics (as in my XHTML vocabulary).

>...
> So now let's imagine a world where you can either POST a  purchase
> order to a website, or if you don't have a web browser, you can
> email the same purchase order to "orders@PaulCo.com", or perhaps if
> you pay to be on PaulCo's "inner circle" list, you can use
> MQSeries to drop a purchase order onto a high speed, reliable queue
> (perhaps with a guarantee of faster service).  

I believe that there is no technological reason that these three users
need three different protocols and all of the interoperability headaches
that three protocols will cause. But this isn't a matter of your believe
versus my belief. We can work it out empirically. If you tell me why you
think that there *must* be these three entry points, and I'll describe
solutions that work better with only one entry point.

I can *easily* give you all of reliability, asynchronousness,
browser-compatibility, browser-independence with *one protocol*. The
only thing you might have to compromise on is ultimate roundtrip
performance but then we're not talking about video game protocols here.

If you develop a meta-protocol that works with few differences over
email, MQSeries and HTTP, it will be exceedingly difficult to get it to
fully adopt the semantics of the HTTP *application protocol* so it will
likely not be a "good player" on the Web.

> ... On the one hand, you
> might say "well, now that there are all these different ways to do
> this, interoperability goes down the drain".  On the other hand,
> if we have a common high-level way of talking about what happens
> when a purchase order is processed, and perhaps even describing it
> in some WSDL-like form, I gain the ability to write software which
> deals with the high level, and allows the infrastructure/middleware
> to handle the actual bindings.  This seems to me to be a good thing.

So you've gained a software development "ability" and reduced
interoperability. How could that be a reasonable choice for a protocol
development standards body?

-- 
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 Sunday, 7 July 2002 12:58:30 UTC