- From: Amelia A Lewis <alewis@tibco.com>
- Date: Thu, 22 Jan 2004 14:03:24 -0500
- To: Tom Jordahl <tomj@macromedia.com>
- Cc: www-ws-desc@w3.org
One further comment seems germane, here.
Part three of the proposal suggests that, since WSDL is defined in terms
of infoset, provision of an alternate serialization is low cost. This
is true. Part one (replacing reference with containment) and part two
(providing portmanteau elements for common idioms) both have strong
potential to increase the complexity of the description of the infoset.
That is, while it is simpler to write:
<definitions>
<service>
<endpoint>
<binding>
<interface>
<operation />
</interface>
</binding>
</endpoint>
</service>
</definitions>
instead of the current form (in which endpoint refers to binding,
binding refers to interface), it does change the infoset, and requires
careful, clear writing in the specification to indicate that *either* an
attribute (reference) or a child element (containment) is permitted, but
not both. Note that W3C XML Schema, the language which we use for
providing the schema for WSDL 2.0, is (notoriously?) incapable of
expressing this sort of co-occurrence constraint; the constraint would
have to live only in the text of the specification.
In like manner, for each idiom formalized into an element, an infoset
component must be created, and it must be modeled in the schema for WSDL
2.0 (and again, the co-occurrence restrictions cannot be expressed in
the schema).
Note that the non-XML syntax should follow the restrictions and
capabilities of the XML syntax closely. This implies that if we are to
undertake a major set of changes to the infoset components, the non-XML
syntax effort should be delayed until that is complete (perhaps general
principles could be worked out, but there are likely to be details that
need careful handling ... which isn't true of the XML syntax, since
we're using well-defined tools).
In all, while I would welcome the part one proposal (containment
alternating with reference), I am dismayed by the scope of changes that
it seems to imply, and uncomfortable with the inability to model
co-occurrence constraints in the schema. I'm fairly indifferent to the
second part (it doesn't feel like something the WG needs to do; these
idioms could also be expressed using extension syntax), and feel that
the third part probably does not belong in scope for the working group,
and, as Tom and Prasad noted, may in fact produce lessened interop.
Amy!
On Thu, 22 Jan 2004 13:21:19 -0500
Tom Jordahl <tomj@macromedia.com> wrote:
>
> I also agree with Prasad and Amy. No one wants WSDL 2.0 to be simple
> and easy for humans (and machines) to understand more that I do. In
> fact this was my primary motivation for joining the working group.
> But this proposal does not strike me as making things simpler for a
> WSDL reader/writer (they will have to know 2 syntaxes) and seems to
> make things very hard for an implementer.
>
> 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.
> >>
> >>
>
--
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com
Received on Thursday, 22 January 2004 14:03:27 UTC