W3C home > Mailing lists > Public > www-ws-desc@w3.org > May 2002

Re: issue: optional parts in <message>?

From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
Date: Thu, 9 May 2002 09:20:13 +0600
Message-ID: <05cc01c1f708$7a466f80$07aa7cca@lankabook2>
To: "Jeffrey Schlimmer" <jeffsch@windows.microsoft.com>, <www-ws-desc@w3.org>
"Jeffrey Schlimmer" <jeffsch@windows.microsoft.com> writes:
> >
> >On #2, I agree with many of the points made below. I think it is
> helpful
> >and clean to be able model at the abstract level  input /output to
> >operations comprising 'n' distinct parts irrespective their fundamental
> >type and nature.
> Reasoning about parts of a message without reasoning about their
> representational type is an intriguing point, but I don't (yet) see how
> this is used by bindings, development-time tools, or automatically
> generated proxies that de/serialize. 
> >IMO, XML Schema is too XML centric and using it model
> >non-XML types is very unnatural.
> I see XML Schema as _the_ interoperable standard for representational
> types, and it would be great if we could (someday) leverage it fully to
> simplify WSDL.

WSDL 1.1 uses XSD as an abstract type description language and not
only a representational language. This is what all the use=literal,
encoded stuff is about. 

We cannot drop that. If we do, we lose the ability to map a WSDL 
description to a non-XML binding.

> >Additionally you want to be able to just
> >drop in existing Schemas (RosettaNet, OAG etc.) rather than having to
> >define XML-Schema wrappers for them and any associated entities such as
> >attachments etc.
> I don't buy this. I don't see how defining an XML Schema wrapper for
> various entities is worse than defining a WSDL message wrapper for the
> same.

The point is that the "message" is what the user needs to define at
that time. Another "type" is not the logical thing that the person is
defining when they indicate that an operation takes a PO and a signature
document say. 

Syntactically, its not very different as Mike Deem carefully illustrated.
I still believe that semantically its very different, so we're knowingly
trading off some semantic clarity with syntactic convenience.

Received on Wednesday, 8 May 2002 23:23:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:23 UTC