[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Announce: A brief history of SOAP

• From: Dave Winer <dave@u...>
• To: "XML-Dev (E-mail)" <xml-dev@l...>
• Date: Tue, 03 Apr 2001 18:19:47 -0700

Yes! I thought about this some more, and there is a distinction. I'll try to
provide an example.

I have a handler that returns all the attributes of a story in a <struct>.

I have scripts that depend on that handler.

However, the person who maintains the code on the server that returns the
attributes could add an attribute and it would not break my scripts. Further
if I want to ever know what's in the struct, I just open it and look because
the <struct>s that go over the wire map into a native data type in my
enviroment, a table, and I have a browser for the table, so the handler's
metadata is visible through a call to the handler. If this still isn't clear
I can do a screen shot.

When I'm developing these things, as I have recently been doing on the
Validator that Andrew mentioned, for example, I have to keep three bits in
agreement:

1. The client.

2. The server.

3. The docs. (Which Andrew and others think of as metadata.)

Now I'd be much happier if I only had to keep 1 and 2 consistent. That third
step is a killer, it's what slows me down.

And inevitably it's the third step that's wrong. :-(

There's a lot more to say about this, for another time, perhaps another
thread -- the importance of "power scripters" -- communities parked at the
intersection of products. Ultimately if two products interop, neither
developer is going to take responsibility for the connection betw the two
(although they always feel it's the other guys job to do it). Fostering of
such communities is necessary to make it work, where they exist, and the
vendors are responsible, you get magic, otherwise, frustrated users.

Dave


----- Original Message -----
From: "Rich Salz" <rsalz@z...>
To: "christopher ferris" <chris.ferris@e...>
Cc: "Andrew Layman" <andrewl@m...>; <xml-dist-app@w...>
Sent: Tuesday, April 03, 2001 6:06 PM
Subject: Re: Announce: A brief history of SOAP


> The risk is in sliding down the slippery slope from "can use" to
> "require."  I am all in favor of the former; the latter is troublesome.
> (It would be a bad thing if XP ever had the phrase "post-validation
> infoset" for example. :)
>
> The SOAP encoding rules allow everything, from completely
> self-describing typed data where there really is no external meta-data,
> to opaque collections of elements whose contents are unparseable without
> XSD or DTD (I forget which).  Would that they had also profiled a simple
> subset.
>
> A general SQL->SOAP database browser might be a useful example to think
> about.
> /r$
>

• Prev by Date: RE: XML Schema Datatype: unanswered questions.
• Next by Date: Re: XML Schema Datatype: unanswered questions.
• Previous by thread: Re: XML Schema 1.1
• Next by thread: RE: Announce: A brief history of SOAP
• Index(es):
  • Date
  • Thread