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