Re: Announce: A brief history of SOAP
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$ >
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format