RE: Simplified WSDL Syntax

As I have indicated in previous mails I am happy to take the alternate
serialization completely off the table. While the idea may be interesting
this group already has enough fish to fry.

I completely agree that inclusion by value hurts re-use and when re-use is
the goal one should include by reference. But in many cases WSDLs are one
offs used for specific projects so the overhead of inclusion by reference
becomes an impediment that we have often found to be insurmountable for
whole classes of users.

What's especially nice, btw, about inclusion by value is that if the WSDL
author decides that they do want to have re-use there is no impediment to
them re-writing the WSDL using inclusion by reference. In other words, the
decision to use inclusion by value is not an irrevocable decision on the
author's part.

As for the mobile folks, in a previous life I did standards work for
Openwave. I can't come up with that many compelling scenarios that would
have me sending WSDLs down to handsets but for those I can foresee I would
actually ask for a mobile profile that mandated inclusion by reference.
Although the size differences are small it actually allows me to have a much
simpler processing model.

		Yaron

> -----Original Message-----
> From: Philippe Le Hegaret [mailto:plh@w3.org]
> Sent: Monday, January 26, 2004 1:04 PM
> To: ygoland@bea.com
> Cc: Web Services Description
> Subject: Re: Simplified WSDL Syntax
>
>
> On Tue, 2004-01-20 at 19:53, Yaron Goland wrote:
> > 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.
>
> I don't see any problem in the WSDL shown as an example. I never count
> the XML elements or attributes in my message. I certainly hate having
> two ways to represent the same content model in a language (a good
> example being RDF). I does make the job of the WSDL writer a little
> easier but it makes the job of the WSDL consumers more
> complicated imho.
> I can already see the mobiles companies asking us to only require only
> of the syntax in order to reduce the memory space of their parsers.
>
> > INCLUSION BY VALUE
> >
> > One basic flexibility that leads to a lot of cost is
> inclusion by reference.
>
> That's more than flexibility. It also encourages the WSDL to
> be reused,
> and helps the maintenance of it (I don't have to rewrite the WSDL if I
> add a new binding for the same service). I recognize that I could be
> convinced your approach as value however.
>
> > SIMPLIFIED SERIALIZATION OF THE INFOSET
> >
> > [...]
> > Even the fully verbose WSDL benefits in terms of
> readability from this
> > encoding:
>
> If languages are going to use some new syntax, I don't really see the
> point of XML anymore. XML is human and machine readable, is mainly
> intended for machines, and is verbose by design.
>  http://www.w3.org/XML/1999/XML-in-10-points
>
> I don't see creating a new language as introducing simplicity in the
> architecture. I certainly see as introducing more confusion and
> complexity in the WSDL processors on the other hand.
>
> > 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.
>
> So, it might be a problem with the tools then, not
> necessarily with the
> language. After all, HTML contains more elements and attributes than
> WSDL. Maybe a mis-perception of the goal of 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.
>
> Not sure how simplifying the case as you proposed would help reaching
> this goal. The current WSDL 2.0 does a clear departure from the RPC
> model since we removed the message construction.
>
> Philippe
>
>

Received on Monday, 26 January 2004 18:07:06 UTC