RE: section 1, intro, for review

> -----Original Message-----
> From: Paul Prescod [mailto:paul@prescod.net]
> Sent: Friday, March 22, 2002 2:18 PM
> To: Don Box
> Cc: www-tag@w3.org
> Subject: Re: section 1, intro, for review
> 
> Don Box wrote:
> >
> >...
> >
> > I agree that the underlying data rep/type system of DCOM (ndr) and
CORBA
> > (cdr) didn't have clean extensibility or versioning built in. The
data
> > rep/type system of web services uses XML and XML Schemas, which have
> > fairly well-understood extensibility mechanisms.
> 
> The common wisdom I have heard around web services is that once a WSDL
> interface is published it does not change. Is your sense different?

No. Had the XML Schema WG tackled versioning, I might argue differently.
But the state of the world today is that XSD/WSDL types cannot change
over time in any reliable sense (which means that yes, they are
immutable).

That stated, one can design an XSD type for extensibility. Today, XSD
supports three mechanisms for evolution.

	1) Element and attribute wildcards (aka xsd:any and
xsd:anyAttribute).
	2) Substitution based on xsi:type.
	3) Substitution using element substitution groups.

Of these, #2 and #3 don't require any a priori work to enable
extensibility. #1 does require the original schema to explicitly support
extension.

> Would the proxies generated by .NET gracefully handle new elements
added
> to an existing one? 

Yes, provided either element wildcards are in use and/or substitution of
a derived type is used.

>I would appreciate it if you could describe the .NET
> web services versioning model or point me to an appropriate resource.

Today, it is what I just described. The WSDL WG may take on versioning -
however, they are just getting started so I don't know if another
approach will be floated.

> > However, this ignores the fact that the community at large wants to
> > build application-specific contracts. In the absence of
XML/SOAP/WSDL,
> > this means that every developer winds up building his own ad hoc
type
> > model and we have no chance of building infrastructure to cope with
it
> > in any sort of general way. SOAP et al give infrastructure more
hooks to
> > recognize what is going on in the network. Totally ad hoc hacks
built
> > using HTTP GET and query strings aren't the answer IMO.
> 
> I'm not sure to what you are referring. I think most people whether in
> the REST camp or the Web Services camp acknowledge that
> application-specific contracts will be strongly expressed in XML
schemas
> of some sort. 

If this is the case, than I believe we are in 100% agreement and we're
simply missing each other due to English language problems.

> The question is whether the documents conforming to those
> schemas are subsumed into some kind of RPC infrastructure, or an HTTP
> infrastructure or no infrastructure at all.

WS-Routing is a great example of one way to abstract away the dependency
on HTTP. So are WSDL bindings.

> >...
> > The SOAP infrastructure (framing using soap:envelope, extensibility
> > using soap:header) are "defined uniform interfaces" that exist
primarily
> > to facilitate better intermediaries. The SOAP payload, however,
tends to
> > convey application-specific semantics, which are unavoidable if we
are
> > to allow developers to continue to innovate in this space.
> 
> We all agree that the payload must be allowed to vary. It does on
> today's web as well! The question is what interoperability is bought
> through the soap:envelope.

Every protocol that has ever succeeded has provided a way to associate
arbitrary gunk with message payload. IP and TCP have very low-level
header extensions. HTTP is much more flexible. Soap:envelope is a bit
more flexible yet, as one can distinguish between mandatory and optional
headers.

DB

Received on Monday, 25 March 2002 21:57:02 UTC