RE: Comments

Thank you for your comments on the WSDL 2.0 spec.  Although we still
have a couple to finish up, the disposition of those we've finished is
indicated below.

The latest drafts incorporating fixes are at [1, 2].  If we don't hear
otherwise within two weeks, we will assume these resolutions are
acceptable to you.

[1] http://www.w3.org/TR/2005/WD-wsdl20-20050510/
[2] http://www.w3.org/TR/2005/WD-wsdl20-adjuncts-20050510/

> -----Original Message-----
> From: public-ws-desc-comments-request@w3.org [mailto:public-ws-desc-
> comments-request@w3.org] On Behalf Of Rich Salz
> Sent: Sunday, November 21, 2004 8:20 PM
> To: public-ws-desc-comments@w3.org
> Cc: Rich Salz
> Subject: 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.

Tracked as LC89a [3], the WG has done considerable work clarifying the
meaning of conformance.  It should be quite clear now from Section 1.2
that the validity to the schema is necessary (though not sufficient)
component of conformance.  We put in a more explicit link to the schema,
and used RDDL at the namespace to allow us to incorporate errata if
necessary in a non-disruptive way.
 
[3] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC89a


> 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.

Tracked as LC89b [4], the WG has also removed the abstract datatypes,
relying directly on XML Schema 1.0 datatypes in our component model.
 
[4] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC89b

> 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.

Tracked as LC89c [5], in removing the abstract datatypes and making the
XML Schema 1.0 schema unambiguously part of conformance, we removed the
ability to use the new features of XML 1.1 (or potentially some future
XML 2.0).  The resulting simplification makes the spec much simpler to
read and separates out the problems of transitioning XML versions from
service description.  XML 1.1 support, when industry demand grows to a
point where support is interesting to more vendors, can be done through
an extension to or future version of WSDL.
 
[5] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC89c

> 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. :)

Tracked as LC89d [6], the WG discussed this alternative along with many
others in designing the composition model for features (and properties).
In the end, we decided against the approach you suggest, though we did
make significant changes and clarifications in the feature and property
composition models.  We instead take essentially the union of the
applicable features and property constraints - if a feature is required
at one level, it cannot be made optional at a lower level.

[6] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC89d

> 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.

Tracked as LC89e [7], the WG already responded to this one at [8], and
we take your response as confirmation you accept this resolution [9].
If that isn't your intent, please let us know.

[7] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC89e
[8]
http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005May/0005
.html
[9]
http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005May/0006
.html

> 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.

Tracked as LC89f [10], the WG agreed to add a definition of a conformant
XML 1.0 document to section 1.2 in addition to defining a conformant
element information item.  This should provide the impetus for
syntax-level interop based on XML 1.0-encoded WSDL 2.0 documents.

[10] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC89f

> 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.

Tracked as LC89g [11], the WG does not agree that the Infoset is a data
model instead of a glossary of terms for talking about XML constructs.
It agreed to fix [owner] (should have been [owner element]).

[11] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC89g

> 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.

Tracked as LC89h [12], the WG did not agree that XML Schema would be
more readable by the intended audience, and preferred to keep the
pseudo-schema and explicit description of each properties.  We closed
this issue without action.

[12] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC89h

> 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.

Tracked as LC89i [13], the WG refers you to our excellent primer [14],
which is now up-to-date with the main WSDL specs.

[13] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC89i
[14] http://www.w3.org/TR/2005/WD-wsdl20-primer-20050510/

> 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.

Tracked as LC89j [15], the WG has not reached a final disposition of
this comment yet, though we expect one within about a week.

[15] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC89j

> 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.

Tracked as LC89k [16], the WG was unable to reach a consensus to engage
in a redesign at this point.  The issue was closed without action.

[16] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC89k

> 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.

Tracked as LC89l [17], the WG felt the component model provided a useful
abstraction that describes precisely the information content and
structure of a description and helps us define the behavior of imports
and includes as serialization details rather than core semantic
concepts.  The WG closed this issue with no action.

[17] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC89l

> 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.

Tracked as LC89m [18], the WG agreed in resolving other comments to
clarifications and fixes to import.  For this issue we specifically
agreed to further fix rows 4 and 5 of table 2-1 to match the other rows.

[18] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC89m


> 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 Tuesday, 24 May 2005 13:17:38 UTC