RE: Simplified WSDL Syntax

We do not necessarily need to make this all or nothing.

At a minimum allowing for inclusion by value rather than reference would
enable a significant savings in complexity. I recognize that this will
require applying restrictions that are difficult to enforce in Schema but I
do not see why that should be a major issue. Schema has numerous flaws, were
we to be bound by them then formats like SOAP would quite literally be
impossible to express. Let us therefore focus on providing the functionality
we need and when Schema fails us let us express that clearly to the schema
working group but otherwise move on.

As for the compressed syntaxes used for common scenarios I think we ignore
these at our peril. WSDL 2.0 is not a virgin effort, it is based on WSDL 1.1
and from WSDL 1.1 we have a lot of experience that lets us know what the
most common scenarios are. At the top of the list is a SOAP message format
with in-out and in-only MEPs. I believe we do a disservice to the users of
WSDL 2.0 if we do not provide a simplified way to express the logic of these
basic scenarios. I recognize that providing such simplification will create
an additional burden for implementers but given that there will be an
enormous (we hope) number of WSDL users and a significantly smaller number
of implementers it seems fair to somewhat inconvenience the later in order
to bring significant benefit to the former. I realize that we cannot burden
the implementers with too much but in this case the trade off seems a fair
one.

As for the alternate serialization, I personally see no reason why we should
hold up Parts 1 - 3 for it.

	Thanks,

		Yaron

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
> Behalf Of Liu, Kevin
> Sent: Thursday, January 22, 2004 2:27 PM
> To: 'Tom Jordahl'; 'www-ws-desc@w3.org'
> Subject: RE: Simplified WSDL Syntax
>
>
>
> +1
>
> Best Regards,
> Kevin
>
>
> -----Original Message-----
> From: www-ws-desc-request@w3.org
> [mailto:www-ws-desc-request@w3.org] On Behalf Of Tom Jordahl
>
> ...
>
> I am very much in favor of defaulting and omitting syntax to
> make the simple
> WSDL simple.  I am not in favor of significantly enhancing the syntax
> (particularly in a way that uses significant white space!) to
> add a "simple"
> and "complex" distinction.
>
> --
> Tom Jordahl
> Macromedia Server Development
>
> -----Original Message-----
>
>
> From: www-ws-desc-request@w3.org
> [mailto:www-ws-desc-request@w3.org] On
> Behalf Of Prasad Yendluri
> Sent: Thursday, January 22, 2004 11:35 AM
> To: www-ws-desc@w3.org
> Subject: Re: Simplified WSDL Syntax
>
>
>  I tend to agree. IMO any simplification is better accomplished via
> things that assume defaults when not specified, rather than
> inventing an
> entirely new syntax for the simplification. Perhaps it is
> worth looking
> at the work done so far from this angle and keeping this in
> perspective
> for work to be done. Lets also keep in perspective the complexity of
> tool implementations that need to handle disparate syntax
> that represent
> the same descriptions. Things like determining the equivalence of two
> WSDLs would get complicated if the syntax is not meshed properly.
>
> Prasad
>
> Amelia A Lewis wrote:
>
> >I can see a use for simplified syntax, but do not see that this is in
> >the charter of the WG to produce as normative.  A useful
> comparison may
> >be drawn with the Relax NG compact syntax, which was
> promoted following
> >the publication of the canonical (XML) syntax, and is only now in
> >process of official-ization (it's a de facto standard
> already; the best
> >kind).
> >
> >I'm not terribly thrilled with this particular implementation of
> >simplification either, but that's rather beside the point.
> I think such
> >a syntax may have value, but that
> >1) it ought to wait for the stabilization of the canonical syntax
> >2) it ought to be worked out and agreed upon externally to
> the working
> >group core, not taken as one of the deliverables per charter
> >
> >I'm particularly uncomfortable with the use of significant
> whitespace,
> >btw.  Python does it well; other examples (make is a
> notorious one) do
> >it very badly.
> >
> >Amy!
> >On Tue, 20 Jan 2004 16:53:54 -0800
> >Yaron Goland <ygoland@bea.com> wrote:
> >
> >
> >
> >>INTRODUCTION
> >>
> >>This letter proposes three new features for WSDL 2.0
> intended to make
> >>it much easier for users to directly interact with WSDL definitions.
> >>The first feature allows for the use of inclusion by value as an
> >>addition to WSDL 2.0's current standard mechanism of inclusion by
> >>reference. The second feature provides simplified elements
> that can be
> >>used to describe common WSDL scenarios. The third feature provides a
> >>simplified serialization for the WSDL 2.0 infoset that makes WSDLs
> >>easier to read and write.
> >>
> >>MOTIVATION
> >>
> >>Below is probably the simplest real world WSDL I could come up with.
> >>
> >><definitions targetNamespace="http://example.com/blip"
> >>                     xmlns:my="http://example.com/blip">
> >>   <types>
> >>      <xs:schema targetNamespace="http://example.com/blip">
> >>         <xs:element name="in" type="xs:string"/>
> >>      </xs:schema>
> >>   </types>
>
> >>   <interface name="aninterface">
> >>      <operation name="anoperation"
> >>pattern="http://www.w3.org/@@@@/@@/wsdl/in-only">
> >>         <input message="my:in"/>
> >>      </operation>
> >>   </interface>
> >>   <binding name="abinding" interface="my:aninterface">
> >>      <wsoap:binding protocol="http://whateveritis"/>
> >>   </binding>
> >>   <service name="aservice" interface="my:aninterface">
> >>      <endpoint name="anendpoint" binding="my:abinding">
> >>         <wsoap:address address="http://ickybick.com/boo"/>
> >>      </endpoint>
> >>   </service>
> >></definitions>
> >>
> >>The previous WSDL has a single in-only operation that is bound to
> >>SOAP. It took 11 Elements & 14 attributes to define this, if one
> >>ignores the contents of the xs:schema element. Each element and
> >>attribute represents a choice that the WSDL designer had to
> make for a
> >>total of 25 decisions.
> >>
> >>A lot of the complexity in designing a WSDL comes from WSDL's
> >>flexibility. Flexibility is a good thing but it isn't something one
> >>should be forced to pay for when one doesn't need it. Put
> another way,
> >>a good design rule is that one should only pay the cost for the
> >>features one needs.
> >>
> >>INCLUSION BY VALUE
> >>
> >>One basic flexibility that leads to a lot of cost is inclusion by
> >>reference. In many cases the separation between service, binding and
> >>interface definitions in a WSDL are really artificial. That is, the
> >>definitions will only be used with each other so the flexibility of
> >>by-reference inclusion adds complexity without benefit.
> >>
> >>Therefore it would seem reasonable to allow implementers a choice
> >>between including information by reference or by value.
> >>
> >>SIMPLIFIED ELEMENTS FOR COMMON CASES
> >>
> >>In addition our experience with WSDL 1.1 shows that a vast
> majority of
> >>features are not used in a vast majority of circumstances.
> This is not
> >>an argument to remove the minority features. The extensibility they
> >>represent is important for WSDL to be able to grow and when they are
> >>needed they are badly needed. But, requiring everyone, everywhere to
> >>pay the full complexity of these features when they don't need them
> >>seems unfair. Therefore I think it would be a reasonable act on the
> >>part of the working group to provide certain shortened
> forms for very
> >>common scenarios. For example, a WSDL interface containing
> nothing but
> >>in-out and in-only and bound to SOAP is likely to be a hugely common
> >>scenario for the immediate future. So why not provide a
> short cut that
> >>would make it easier to read and write such common patterns?
> >>
> >>Below I give an example of a WSDL defined using a combination of
> >>by-value and simplified patterns for common usage scenarios.
> >>
> >><definitions targetNamespace="http://example.com/blip"
> >>                     xmlns:my="http://example.com/blip">
> >>   <service name="my:service">
> >>      <interface>
> >>         <soapinoperation protocol="http://whateveritis">
> >>            <inmessage>
> >>               <xs:schema targetNamespace="http://example.com/blip">
> >>                  <xs:element name="in" type="xs:string"/>
> >>               </xs:schema>
> >>            </inmessage>
> >>         </soapinoperation>
> >>      </interface>
> >>      <soapendpoint address="http://ickybick.com/boo"/>
> >>   </service>
> >></definitions>
> >>
> >>7 elements and 6 attributes = 13 decisions (ignoring the contents of
> >>the xs:schema element)
> >>
> >>This is a 48% reduction in complexity. The inevitable cost for
> >>reducing complexity is a reduction in choice but given that the
> >>previous, if we threw in in-out, represents the 80% case for Web
> >>Service WSDLs this seems a reasonable price to pay.
> >>
> >>SIMPLIFIED SERIALIZATION OF THE INFOSET
> >>
> >>There is another step we can take, inspired by XQUERY, which is to
> >>provide an alternate serialization to XML. Since WSDL is defined at
> >>the InfoSet level providing such an alternate serialization is not a
> >>major challenge.
> >>
> >>definitions targetNamespace = "http://example.com/blip"/
> >>                   xmlns:my = "http://example.com/blip"
> >>   service name="my:service"
> >>      interface
> >>         soapinoperation protocol="http://whateveritis"
> >>            inmessage
> >>               xs:schema targetNamespace = "http://example.com/blip"
> >>                  <xs:element name="in" type="xs:string/>
> >>      soapendpoint address="http://ickybick.com/boo"
> >>
> >>The previous uses a strict positional system to encode
> element names.
> >>3 spaces equal one 'level'. So you know that soapin is a child of
> >>interface because soapin is 3 space farther in than interface. WSDL
> >>responds well to such a system because most elements have relatively
> >>little content. For some things, such as schema, one
> probably wants to
> >>just use XML and so that is made possible. A simple encoding rule,
> >>that any child that starts with < is XML, makes it trivial
> to mix XML
> >>and non-XML content.
> >>
> >>Even the fully verbose WSDL benefits in terms of
> readability from this
> >>encoding:
> >>
> >>definitions targetNamespace="http://example.com/blip"/
> >>                  xmlns:my="http://example.com/blip"
> >>   types
> >>      xs:schema targetNamespace="http://example.com/blip"
> >>         <xs:element name="in" type="xs:string"/>
> >>
> >>   interface name="aninterface"
> >>      operation name="anoperation"/
> >>
> pattern="http://www.w3.org/@@@@/@@/wsdl/in-only"
> >>         input message="my:in"
> >>
> >>   binding name="abinding" interface="my:aninterface"
> >>      wsoap:binding protocol="http://whateveritis"
> >>
> >>   service name="aservice" interface="my:aninterface"
> >>      endpoint name="anendpoint" binding="my:abinding"
> >>         wsoap:address address="http://ickybick.com/boo"
> >>
> >>CONCLUSION
> >>
> >>It is fair to ask - why do we care? What's the big deal of
> cutting the
> >>number of attributes and elements in half? Byte bloat can't be that
> >>big a deal, can it?
> >>
> >>The answer is that our experience with WSDL 1.1 worries us
> deeply. We
> >>have found that the majority of our customers cannot read or write a
> >>WSDL, not even with a tool. The result is that customers
> are generally
> >>unwilling to use WSDL outside of the very specific scenario of
> >>RPC/Encoded where they treat WSDL as an opaque IDL definition.
> >>
> >>We firmly believe that for Web Services to meet its promise
> users must
> >>start to build loosely coupled/large grained messages and
> for that to
> >>happen users must become comfortable with WSDL.
> >>
> >>Therefore we believe it is crucial that normal users in normal
> >>circumstances be able to both read and write WSDLs so that they will
> >>feel comfortable in leaving behind RPC and moving towards real loose
> >>coupling and large grained messaging.
> >>
> >>
>
>

Received on Friday, 23 January 2004 18:22:18 UTC