Minutes, 15 January 2004 Web Services Description Working Group teleconference

Minutes, 15 January 2004 Web Services Working Group Teleconference

Present:
 Mike Ballantyne        Electronic Data Systems
 David Booth            W3C
 Allen Brookes          Rogue Wave Software
 Roberto Chinnici       Sun Microsystems
 Paul Downey            British Telecommunications
 Tom Jordahl            Macromedia
 Jacek Kopecky          Systinet
 Sandeep Kumar          Cisco Systems
 Philippe Le Hégaret    W3C
 Amelia Lewis           TIBCO
 Kevin Canyang Liu      SAP
 Lily Liu               webMethods
 Jonathan Marsh         Chair (Microsoft)
 Ingo Melzer            DaimlerChrysler
 Jeff Mischkinsky       Oracle
 Jean-Jacques Moreau    Canon
 David Orchard          BEA Systems
 Bijan Parsia           University of Maryland MIND Lab
 Arthur Ryman           IBM
 William Vambenepe      Hewlett-Packard
 Sanjiva Weerawarana    IBM
 Umit Yalcinalp         Oracle

Regrets:
 Glen Daniels           Sonic Software
 Youenn Fablet          Canon
 Dietmar Gaertner       Software AG
 Dale Moberg            Cyclone Commerce
 Jeffrey Schlimmer      Microsoft
 Igor Sedukhin          Computer Associates
 Jerry Thrasher         Lexmark
 Prasad Yendluri        webMethods, Inc.

Scribe: Amelia Lewis

Topic: Approval of minutes
Minutes for 8 January 2004 approved.

Topic: Review of action items
Umit on normalized dispatching: pending
Paul on vectors and arrays in primer: moved to ed todo
Paul on schemas in primer: pending
Jacek on concrete RPC hinting proposal: pending

Topic: Administrivia
Discussion of plans for January face to face (attendance, cost).
Discussion of pending work on review of web architecture document

Topic: Task force status
Task force on media types, joint with XMLP and XML Schema WGs, needs
help.  Call for involvement.  Result of task force is currently expected
to be a W3C Note, or the equivalent.

Topic: New issues
Paul's issue on versioning added.  Feedback on issues around versioning
of web services solicited.

Topic: Two logical WSDL documents
Email discussion continuing; encouraged as proper forum.  Single
interface per service issue not reopened, but noted as a possibility for
face to face.

Topic: Abstract faults
Summary: move faults up to interface level and adjust the language to
refer to these definitions, rather than repeating them in each
operation.
Paul: reduces redundancy, clarifies the scope of usage of faults
Tom Jordahl: this solves problems, we should use it.
Sanjiva: agrees.
Paul: concerned that there has been little pushback or discussion;
perhaps folks are just not interested?  Others make it clear that this
is not the case, but equally that further discussion is desired.
Tom Jordahl: concerned that this will again require great verbosity in
bindings, to no purpose; wants to keep bindings empty in the common
case.
Jonathan: asks for formal proposal, illustrating differences from the
current spec and the changes which will be required.
Roberto: points out problem with messageRef attribute following the
abstract fault definition, since it refers to something defined inside a
MEP.
Paul: agrees that problem exists, undertakes to fix it.  Since
amendments have been made, Paul will combine, revise, and resubmit for
further discussion.

ACTION: pauld to revise abstract faults proposal and submit to list
ACTION: sanjiva to sketch out changes to abstract model [resulting from
abstract faults proposal]

General agreement that more examples and information would be useful.
Jonathan: calls for available WSDL examples that can be contributed to
test and examples collections
Sanjiva: several available which are conversions of existing public web
services (amazon, google)
Paul: have internal materials, may be able to submit following IPR
review.

Topic: Fault name uniqueness
Agreement to defer this until resolution of the abstract faults topic,
which may solve it with no further effort.

Topic: Issue 85, HTTP binding
Philippe: there have been delays in producing a revision following
comments.
Sanjiva: (joking, mostly) can the binding be dropped?
Philippe: it's in the charter, so no.
Scribe: falls for the joke and records it seriously.  Considers adding
resolution of single interface per service issue in a more congenial
form, but decides that someone somewhere probably does read minutes, so
refrains.
Questions remain on the scope of the HTTP binding.  How complex should
our support be?  Discussion becomes rather general for a time. 
Reference made to Sanjiva's post describing five levels of possible
support.  General agreement that level three is as low as possible, but
disagreement on where in the range 3-5 to settle.  Sanjiva likes 3 or 4,
tending toward 3.  Umit asks what was wrong with 4; Jonathan describes
that level, and suggests that its difference from 5 is chiefly the lack
of a generalized mechanism for URL replacement.
Discussion becomes more focused, on the question of how URL replacement
should work.
General agreement that, regardless of what is placed in the URL (or how,
whether query parameters or URL rewriting), all of the information is
replicated in the message body.  Also general agreement that what
appears in the URL may be a subset of the full message.
Call for feedback on Philippe's proposal.
Philippe asks: should we allow complete URL replacement (changes to
portions of the URL other than query parameters) or only query parameter
mechanism?
Sanjiva suggests that anything above 3 is overkill for SOAP 1.2.
Philippe argues that the binding is for HTTP 1.1, and that the SOAP 1.2
binding is not yet under discussion.  Agreement from Jacek.  Sanjiva
objects that this means that there could potentially be two very
different ways of achieving the same purpose (message encoded in URL)
for HTTP versus SOAP.
Question raised as to whether all possible schemas can be encoded in a
URL, or only a restricted subset.
Philippe responds that only RPC style can be encoded.
Sanjiva describes the restrictions in detail; Philippe agrees with the
summary.
David Orchard questions whether this requirement for RPC is compatible
with the current move toward doc/literal messaging.
Umit suggests that the use of "RPC" in this context is misleading, as
the mechanism for RPC in WSDL 2.0 is different from that in 1.1, and
these restrictions on what may be encoded in a URL are different from
the restrictions on RPC.  In other words, the apparent conflict only
arises due to overloading the term "RPC".
Philippe agrees, and offers to call it something other than RPC.
Scribe loses the thread of discussion for a few minutes.  Considers
mentioning discussion of flat-top versus braided styles, but again
decides that minutes sometimes get read and nobly restrains herself.
Jonathan tries to survey WG for strong feeling, pro or con, on the
question of including a general mechanism for URL replacement (versus
the query parameters mechanism, which is not in question).  Results show
a fair number of people with opinions on both sides, and a large number
who don't speak up (either not having an opinion or not willing to talk
about it before a vote).
Sanjiva asks for examples of use of URL replacement mechanism as defined
in WSDL 1.1.  Philippes suggests that there are implementations; Sanjiva
objects that implementation is different from use.  Sanjiva follows up,
in a dialog with Tom Jordahl about how Axis implements URL replacement,
illustrating that known implementations in fact only do query
parameters, not the more complex forms.
David Orchard objects that the absence of evidence of use may not
indicate that the mechanism is unneeded, but could instead mean that, as
defined, it is hard to use (scribe adds that absence of evidence is not
evidence of absence).
Umit provides a use case, suggesting that where a module adds soap
headers, URL replacement for HTTP can provide a similar means of adding
"headers" to a message.
Jacek want to ask (this group, or arch or tag) whether a Web Service is
a single HTTP resource or a set of resources.  If it is a set of
resources (implying multiple URLs, not just differing query parameters
to a single URL), then a full, general mechanism for URL replacement is
needed.  He believes that it is a set, not single.
David Orchard suggests that it is odd to call it Web Services
Description Language if it can't describe all the URLs on the web.
More folks call for use cases and examples.
Philippe offers, as an example of the distinction being drawn, these two
URLs (full replacement form first, query parameters only form
following):
http://cars.example.org/AAA555/color
http://cars.example.org/AAA555?property=color
Jonathan proposes that this feature be taken into CR, since it can be
dropped without causing delay between CR and PR (no required return to
LC/WD).  David Orchard confirms.  Philippe outlines the "features at
risk" mechanism.  Pro: allows it to get exposure, and there doesn't seem
to be consensus to remove it now, but if listed at risk it can be
dropped prior to PR without danger.  Con: working on the feature
requires time and effort, which, if we expect it to be dropped, will be
wasted (and could otherwise be used for other, less risky features).
Jonathan suggests that the feature remain, for now, with a poll to be
taken at the march face to face to determine future direction.
Philippe or Sanjiva raises the question of whether the body will be
supported in text/xml encoding only, or whether the alternate
x-www-url-encoded (forms encoding) syntax will also be supported.
The use case here is to permit a standard web browser to interact with a
web service.  Philippe questions the utility of doing so.
In this case, the resolution is to not support forms encoding, but
rather to wait until someone raises it as an issue (if someone cares
enough to do so).

ACTION: Philippe to work up a more formal proposal for the HTTP binding.

Philippe's revised proposal will be added directly (with no further
review required) to part three.  Issues may then be opened against it. 
Jonathan mentions four existing open issues.  Jean-Jacques asks the
scribe to include them in the minutes, but Jonathan talks faster than
the scribe types (or listens, or thinks, for that matter ... XML is
*hard*).  Jonathan supplies the URL for the currently open issues on
part three (but add the question of whether to include a full general
mechanism for URL replacement, too):
http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0059.html
Jean-Jacques will add these (there are three) to the issues list, along
with the URL replacement issue.

Jonathan suggests that the WG should concentrate on parts 1 & 2 in order
to achieve the targeted LC for the march face to face.

Meeting adjourned, 12:32:07 2004 EST


Topic: New action items
ACTION: pauld to revise abstract faults proposal and submit to list
ACTION: sanjiva to sketch out changes to abstract model [resulting from
abstract faults proposal]
ACTION: Philippe to work up a more formal proposal for the HTTP binding.


-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Thursday, 15 January 2004 14:13:25 UTC