After investigating this, it appears to me that implementing the
by-value proposal requires a complete rewrite of part one of the
specification, in effect, and makes the job of WSDL processor
implementor significantly more complex. Based on previous experience,
so large a task as rewriting the content model of every component in
part one would require a minimum of six months (I'd be surprised to see
it go that fast, actually).
There's certainly significant value in making it easier on the writers
of WSDL (as opposed to the writers of WSDL processors). I wish that
this had been proposed a year ago; I probably would have supported it,
with careful attention to clarifying potential ambiguities for authors
of WSDL processors. I'd still be interested to see what it looks like
if someone is willing to take on the burden of rewriting all of part
one. But I don't think I'm willing to vote in favor of adding it to
the requirements for the working group, at this stage of progress,
without a very convincing demonstration of the ease of integration
(that is, a draft of a rewrite of part one rather than a requirement
that the group and its editors engage in producing same).
Amy!
On Jan 26, 2004, at 6:04 PM, Yaron Goland wrote:
>
> 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
>>
>>
>