Comments

Last week, O'Reilly published a column I wrote about WSDL 2.0; in
subsequent email, Jonathan suggested I send comments to the list.
I appreciate the chance to do so, and fully recognize that this is
well after the deadline.  Still and all, when given an opportunity
to carp, I'll not turn down the invite. :)

In order to reduce overhead, I'll try to bundle everything in this one
message.  If you prefer separate notes, let me know.

1.  Is schema-validity a conformance point, or not?  The table
    entry for the "wsdl" namespace prefix mentions a normative
    schema, yet the conformance section talks about information
    model. These two items seem in conflict, and burying the
    schema mention as an aside in a listing of namespace prefixes
    makes it all too easy to dismiss.  I could not find the schema
    in the documents, either.

2.  Abstracting away from XSD datatypes is a mistake. It is eminently
    reasonable to bind yourself to the official W3C schema and data-
    type language.  IT seems foolish to introduce a new type suite
    (and terms such as "actual value") that will almost always map
    directly onto XSD.  Does anyone in the WG know of any plans to
    do otherwise?  This leads into my next point.

3.  Abstracting away XML 1.x and 2.x is a mistake.  There is too much
    tortured language and complexity by trying to support two incompatible
    formats called XML.  I suggest that support for XML 2.0 is premature:
    it has no Infoset, no Schema, and (yes, because of no schema), no
    SOAP support -- let alone other web services related specifications
    such as XML Digital Signature.  The hardest part of standardization
    is making the right trade-off.  Defer XML 2.0 and you can lose
    the resultant complexity and type redundancy, and you'll be
    making the right exchange.

4.  It doesn't seem possible to define a Feature (sec 2.8) at the Interface
    level, yet disable it for a specific operation.  Unlike my other
    points, this is arguably more of a feature request. :)

5.  Properties, which are relevant to a specific runtime instance, do not
    belong here, but rather in a separate file.  WSDL is a network service
    contract; putting per-implementation information here, which may be
    completely inappropriate or wrong for two installations of the same
    runtime, only encourages non-portable service definitions.

6.  Following on the previous item, syntax should dominate.  The most
    important thing about WSDL should be that it is a *portable* description
    of a service interface.  It is crucial that end-users be able to take
    a WSDL file from one platform and use it on another.  Infosets are
    not portable; they are useful to runtime and compiler implementors
    here, not developers using WSDL. The conformance points must be
    strengthened, and end-users must have a clear understanding of what
    it means to write a conforming WSDL file.

7.  The phrase "XML representation" as used throughout (e.g., sec 2.5.2)
    is wrong.  The XML representation is the syntax; the Infoset is not
    a representation, it is a data set. Another confusion is the use of
    "[owner]" which looks like an Infoset item, but isn't. My point here
    is that there is much bleed-through, and a confusing mix between
    XML syntax (not enough), non-normative psuedo-schema, XML Infoset,
    and WSDL Component Model.

8.  Much redundancy and lack of clarity could be avoided by using XML
    Schema.  Every (or almost every) section that describes a WSDL
    component follows the same outline:
        A short bit of prose
        Non-normative psuedo-schema
        Infoset description
        Component properties
    Almost all of the middle two sections could be removed by
    including normative XSD fragments.  This would have the benefit
    of being both more precise and less verbose.  I have heard the
    argument that the psuedo-schema is useful to most readers. My
    counter-argument is that this recommendation is targeted to
    WSDL developers, not casual web services developers (although
    I wish it otherwise), and familiarity with XSD can be assumed.

9.  A primer is needed. This follows from #6. Just as SOAP and Schema
    have primers targeted toward end-users, so should WSDL. I'd argue,
    in fact, that while you can "hide" the details of SOAP from most
    end-users, you *cannot* do the same for WSDL.

10. The numerous "Note"'s about name uniqueness are a big warning sign
    that something is wrong.  XML has the technology to avoid
    local-name conflicts, and the current scheme gives only the
    illusion of independent distributed service development.  Proper
    use of namespaces can completely obliterate this problem area.

11. The inheritance model isn't necessary. Rather than cram everything
    into one target namespace, allow a service to implement multiple
    endpoints. The conformance point could be "at least one"; ability to
    support multiple namespaces is then a quality of implementation (i.e.,
    marketplace) issue. This would also address #10.

12. The component model, necessary for equivalence, which in turn is
    necessary for the inheritance model, is a bad idea. Fixing #11
    will partly remove the primary need for the component model.
    Adding some additional "ref" (or href/id) attributes to make all
    linkages explicit (those that don't follow the in-scope model),
    and the component model can be completely removed from the
    recommendation.

13. If I understand it correctly, then I am not sure the "directly
    include" concept is useful.  If "a.wsdl" imports "b.wsdl", then
    the types section of the first must reproduce any imports
    in the types section of the second.  If true, this isn't the way
    conventional programming languages work, and since XSD already
    has mechanisms to address multiple inclusion, it seems to needlessly
    require "a.wsdl" to have internal knowledge of "b.wsdl".
    necessary.

Thank you for your consideration.  I would be happy to discuss these
further.
        /r$
-- 
Rich Salz                  Chief Security Architect
DataPower Technology       http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
XML Security Overview      http://www.datapower.com/xmldev/xmlsecurity.html

Received on Monday, 22 November 2004 04:20:22 UTC