Re: Announce: A brief history of SOAP

Jake Savin wrote:

> I'm not disagreeing with the idea that metadata should be standardized -- I
> think it should.
>
> All I'm saying is that a given implementation shouldn't be required to
> interpret the metadata, if it's available in some other form (like
> programmer docs).
>
> Specs which require the (programmatic) interpretation of standardized
> metadata place a large burden on the implementors of the spec, IMHO
> unnecessarily.
>
> (I don't think we disagree on this point, but I wanted to make my POV
> clear.)

Perhaps the desirable answer here is to separate the two; specifying the
"transport' (XMLP)
one one spec, and having a distinct (layered) specification defining an
interoperable "web service"
that would describe service meta-data.

That way everyone is happy, and we will have introduced not one but two new
specifications into the world!

8^)

- Larry


>
>
> Thanks,
> -Jake
>
> on 4/4/01 3:52 AM, Leigh Dodds at ldodds@ingenta.com wrote:
>
> > Just to de lurk for a moment:
> >
> > This discussion seems reminiscent of OO developers discussing the
> > addition of Run Time Time Information (RTTI, or Reflection to java types)
> > to an OO language.
> >
> > Adding RTTI allows you to do a lot of neat things that you couldn't do
> > perform, and gives some new ways of doing things you could already do.
> >
> > However this doesn't invalidate all the code you've already written that
> > doesn't use RTTI.
> >
> > Programmers can read the docs to discover facilities. Applications can
> > inspect
> > code using RTTI.
> >
> > Same goal, but for different audiences. No need to require one way or
> > another.
> > From what I've followed so far, all that has been suggested is that the
> > metadata (RTTI information) should be standardised.
> >
> > I haven't seen anyone suggest that all programmer documentation for
> > Java now that it has a reflection package.
> >
> > <lurk-mode/>
> >
> > L.
> >
> > --
> > Leigh Dodds, Systems Architect       | "Pluralitas non est ponenda
> > http://weblogs.userland.com/eclectic |    sine necessitate"
> > http://www.xml.com/pub/xmldeviant    |     -- William of Ockham
> >
> >> -----Original Message-----
> >> From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
> >> Behalf Of Jake Savin
> >> Sent: 04 April 2001 11:38
> >> To: xml-dist-app XML Distributed Applications List
> >> Subject: Re: Announce: A brief history of SOAP
> >>
> >>
> >> Larry,
> >>
> >> I respectfully disagree. Requiring that metadata is in a standard format
> >> (like WSDL) raises the bar too high. I can do a hell of a lot
> >> with only the
> >> simple knowledge of what method to call at what endpoint, and with what
> >> parameter types (and names).
> >>
> >> I don't need WSDL (or any SDL) for that. Human-readable docs are more than
> >> enough.
> >>
> >> If you can parse a standard service description, and if that
> >> helps you, then
> >> more power to you, but requiring that I do the same isn't fair.
> >>
> >> -Jake
> >>
> >> ps. (I'd replied to this message yesterday, but accidentally only sent the
> >> reply directly to Larry, instead of to the list -- my apologies.)
> >>
> >> on 4/3/01 3:58 PM, Larry Cable at larry.cable@sfbay.sun.com wrote:
> >>
> >>> Andrew Layman wrote:
> >>>
> >>>> If I send you a message such as
> >>>>
> >>>> <Translate>
> >>>> <gamma>123.45</gamma>
> >>>> <epsilon>.67</epsilon>
> >>>> <pi>3.14159</pi>
> >>>> </Translate>
> >>>>
> >>>> then you presumably either have somehow got some idea what this message
> >>>> means and what its structure is etc., or you don't and cannot
> >> process it
> >>>> (except as generic XML).  However you got the knowledge, that was the
> >>>> metadata.
> >>>>
> >>>> In the case of the messages sent to the "SOAP Validator" at UserLand's
> >>>> site, the documentation describing the messages is the metadata.
> >>>>
> >>>> I don't think you can do much without some metadata.  The only issue is
> >>>> the form that the metadata takes, largely whether it is in a standard
> >>>> form or not.
> >>>
> >>> I concur, furthermore I would reinforce your assertion that a
> >> std mechanism
> >>> for describing such meta-data
> >>> is a "requirement" in order to enable both static and dynamic service
> >>> discovery and subsequent conversations.
> >>>
> >>> Rgds
> >>>
> >>> - Larry Cable.
> >>>
> >>>>
> >>>>
> >>>> -----Original Message-----
> >>>> From: Dave Winer [mailto:dave@userland.com]
> >>>> Sent: Tuesday, April 03, 2001 3:31 PM
> >>>> To: xml-dist-app@w3.org
> >>>> Subject: Re: Announce: A brief history of SOAP
> >>>>
> >>>> Andrew I don't know enough about the kinds of environments you use, but
> >>>> I'm
> >>>> with Fredrik on this. We do just fine without any meta data. No
> >>>> "requires"
> >>>> here. Dave
> >>>>
> >>>> ----- Original Message -----
> >>>> From: "Andrew Layman" <andrewl@microsoft.com>
> >>>> To: <xml-dist-app@w3.org>
> >>>> Sent: Tuesday, April 03, 2001 12:07 PM
> >>>> Subject: RE: Announce: A brief history of SOAP
> >>>>
> >>>>> I think that the point is that any exchange of messages via SOAP (or
> >>>>> otherwise) requires that the parties have mutual access to some sort
> >>>> of
> >>>>> metadata describing the types of the data being exchanged.  WSDL
> >>>>> provides such metadata in an implementation-neutral way that supports
> >>>>> and leverages the W3C specifications such as Schema.
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: Fredrik Lundh [mailto:fredrik@pythonware.com]
> >>>>> Sent: Saturday, March 31, 2001 2:35 AM
> >>>>> To: Box, Don
> >>>>> Cc: xml-dist-app@w3.org
> >>>>> Subject: Re: Announce: A brief history of SOAP
> >>>>>
> >>>>>
> >>>>>> You can read it at http://www.develop.com/dbox/postsoap.html
> >>>>>
> >>>>> "Does SOAP/XML Messaging make sense without something like
> >>>>> WSDL? No way"
> >>>>>
> >>>>> huh?  I've got lots of users for my python soap implementation,
> >>>>> and now you're saying that what they do doesn't make sense?
> >>>>>
> >>>>> what have we missed?
> >>>>>
> >>>>> Cheers /F
> >>>>>
> >>>
> >>
> >

Received on Wednesday, 4 April 2001 12:41:06 UTC