RE: HTTP binding options

After some discussion, I think that what I've been hearing is a bit more of
a refinement.  I think I could live with an entire GED always being
serialized, and also have some bindings serialize a part of the GED into an
alternate encoding, such as a URI.  In the case of something like a
brokerage transaction, the transaction # could go into the URI but would
need to go into the envelope.  While it might be cleaner to specify
either/or, I could live with duplicate.  Also, I can live with a subset of
xml schema types, such as strings, being serialized into URIs.  Last year I
looked at doing a generalized xml->uri->xml mapping for soap envelopes, and
it's not worth it imo.

Cheers,
Dave

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
> Behalf Of David Orchard
> Sent: Wednesday, November 12, 2003 10:45 AM
> To: 'Glen Daniels'; www-ws-desc@w3.org
> Subject: RE: HTTP binding options
>
>
>
>
> > I don't think the use case of defining a single service where
> > some uses
> > serialize the entire GED in the message, and other uses
> > serialize parts of
> > the GED as URL-construction-blocks seems very realistic.
> Can someone
> > present a use-case for such a thing?
> >
>
> hmm, I don't think I'm advocating that.  I thought I was
> advocating that a
> service has an interface that can choose via the binding whether to
> serialize all or only some or even none of the GED into the envelope.
>
> > Note that I'm not in any way against parameterizable URLs for
> > REST-type
> > services.  I just think there's got to be a better way to do
> > it than ripping
> > apart the described message contents.
> >
>
> Could you elaborate on a better way?  Perhaps I jumped to the
> solution when
> I thought I was jumping at the requirement...  We might be in
> agreement and
> it's just that I don't have enough of the context to express it in an
> appropriate manner.
>
> cheers,
> Dave
>
>

Received on Wednesday, 12 November 2003 19:41:46 UTC