- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Thu, 15 Jul 2004 15:58:44 -0700
- To: <www-ws-desc@w3.org>
Web Services Description Working Group
Minutes: 15 July 2004 telcon
Present:
Erik Ackerman Lexmark
David Booth W3C
Allen Brookes Rogue Wave Software
Helen Chen Agfa-Gevaert N. V.
Roberto Chinnici Sun Microsystems
Ugo Corda SeeBeyond
Glen Daniels Sonic Software
Paul Downey British Telecommunications
Hugo Haas W3C
Tom Jordahl Macromedia
Amelia Lewis TIBCO
Jonathan Marsh Chair (Microsoft)
Jeff Mischkinsky Oracle
Dale Moberg Cyclone Commerce
Mark Nottingham BEA Systems
David Orchard BEA Systems
Jeffrey Schlimmer Microsoft
Igor Sedukhin Computer Associates
Asir Vedamuthu webMethods
Sanjiva Weerawarana IBM
Umit Yalcinalp Oracle
Prasad Yendluri webMethods, Inc.
Regrets:
Youenn Fablet Canon
Martin Gudgin Microsoft
Jacek Kopecky DERI
Kevin Canyang Liu SAP
Peter Madziak Agfa-Gevaert N. V.
Jean-Jacques Moreau Canon
Bijan Parsia University of Maryland MIND Lab
Arthur Ryman IBM
Jerry Thrasher Lexmark
--------------------------------------------------------------------
Agenda
1. Assign scribe. Lucky minute taker for this week is one of:
Adi Sakala, Umit Yalcinalp, Igor Sedukhin, Dale Moberg,
Hugo Haas, David Orchard, Jerry Thrasher, Allen Brookes
Scribe: Hugo
--------------------------------------------------------------------
2. Approval of minutes:
- July 8 [.1]
[.1] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0109.html
Postponed until next week
Waiting for MarkN
--------------------------------------------------------------------
3. Review of Action items [.1].
PENDING 2004-04-01: Marsh will get schema tf going.
?ED 2004-05-19: Editors to include in the primer an example
that uses MTOM. (Issue 72)
?ED 2004-05-20: Editors to incorporate Hugo's full potato
proposal. (Issue 54)
Discussions around the full potato proposal
Hugo: http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0244.html
is missing
?ED 2004-05-20: David Orchard to update HTTP binding to
include discussion of how to generate an
accepts header from schema annotations
conformant to the media types extension
document, and to use outputSerialization
based on that information.
Accept header discussion: the discussion needs to be revived
?ED 2004-05-21: Editors to add ednotes to the spec to
indicate areas that had contention. (Issue
190)
Issue 190 and editor note: proposal for links to any minority objections
from the status section for other votes
RESOLUTION: link to minority opinions from the status section
ACTION: people who want to file a minority opinion should do so by July
22
?ED 2004-05-27: Editors to add http:faultSerialization
attribute.
DONE 2004-06-10: Editors should correct issue 208, come
back to WG if there are any questions.
DONE 2004-06-10: Editors should correct issue 213, come
back to WG if there are any questions.
DONE 2004-06-10: Editors should correct issue 215, come
back to WG if there are any questions.
?ED 2004-06-17: Editors to incorporate David Booth's clarification
in section 8.3 about what required means on MTOM
feature.
DONE 2004-06-24: Editors to incorporate Jonathan's resolution
to issue 160.
DONE 2004-06-24: Editors to fix media-type reg frag id link,
per 209.
?ED 2004-07-01: Editors to add cross-references for component
properties, per DBooth's example.
DONE 2004-07-08: Editors to deal with issue 227, come back to
the WG with issues if any.
?ED 2004-07-08: Editors to deal with issue 235, come back to
the WG with issues if any.
DONE 2004-07-08: Editors to deal with issue 231, come back to
the WG with issues if any.
DONE 2004-07-08: Editors to deal with issue 232, come back to
the WG with issues if any.
DONE 2004-07-08: Editors to deal with issue 234, come back to
the WG with issues if any.
?ED 2004-07-08: Editors to deal with issue 226, come back to
the WG with issues if any.
?ED 2004-07-08: Editors to implement resolution to 177 as
amended.
(Part 3 component remains.)
DONE 2004-07-08: Editors to add f&p to Interface Fault, Binding
Fault, and Fault References. (Issue 228)
PENDING 2004-07-08: Glen to verifiy composition model.
DONE 2004-07-08: Editors to add the optional AD feature to
Part 2 (Issue 112).
(note big changes!)
DONE [.2] 2004-07-08: Hugo to send email about AD feature setting
HTTP header it shouldn't set.
DONE 2004-07-08: Part 2 editors to adopt MarkN's resolution for
issue 230 (use {message label}).
DONE 2004-07-08: Editors to deal with issue 220, come back to
the WG with issues if any.
DONE 2004-07-08: Editors to adopt Amy's proposal for Issue 233.
[.1] http://www.w3.org/2002/ws/desc/#actions
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0131.html
---------------------------------------------------------------------
4. Administrivia
a. - August 2-4 (London)
Logistics [.1], registration [.2].
- September 14-16 (Toronto) [.3]
- November (West Coast) 8-10 webMethods Sunnyvale, CA.
Results of poll on moving to 9-11 [.4]
November F2F moved from 8-10 to 9-11
Paul: is there any logistics for Toronto?
Jonathan: I'll follow up with Arthur
* dbooth-fl (muted) logistics page is there but not yet announced or
updated with the changed dates.
* dbooth-fl I don't have a logistics page for September yet.
b. XMLP WG response to our comments [.5, .6]
Postponed.
[.1] http://www.w3.org/2002/ws/desc/4/04-08-f2f.htm
[.2] http://lists.w3.org/Archives/Member/w3c-ws-desc/2004Mar/0064.html
[.3] http://lists.w3.org/Archives/Member/w3c-ws-desc/2004May/0000.html
[.4] http://lists.w3.org/Archives/Member/w3c-ws-desc/2004Jul/0008.html
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0036.html
[.6] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0006.html
------------------------------------------------------------------
5. Task Force Status.
a. Media type description
- 1st Working Draft Published [.1]
b. MTOM/XOP
- Last Call Published [.2]
c. QA & Testing
- Suggested QA plan [.3]
- More details from Arthur [.4]
- Interop bake-off
d. Schema versioning
- Waiting to hear back from Schema on my draft "charter."
- Henry's validate-twice write-up [.5]
[.1] http://www.w3.org/TR/2004/WD-xml-media-types-20040608/
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0052.html
[.3]
http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/att-0029/QA_Oper
ational_Checklist.htm
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0037.html
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0019.html
------------------------------------------------------------------
6. New Issues. Issues list [.1].
- Issue 239: Part 1 Editorial Issues (Asir) [.2]
Already fixed!
- Issue 240: input serialization flexibility (DaveO) [.3]
- Issue 241: AD Feature: HTTP header conflicts (Hugo) [.4]
- Issue 242: Binding accepts header and output serialization (Hugo)
[.5]
[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0110.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0073.html
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0131.html
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0005.html
All new issues are on the agenda
Agenda:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0238.html
------------------------------------------------------------------
7. Editorial issues:
- Roberto's editorial comments [.1]
If resolved, indicates closure of the following editorial issues:
- 208 Misc. editorial comments
- 213 Refine component model property constraints
- 215 Clarify rule obviation
- 220 Document interface extension semantics
- 227 Description of Binding Operation component
- 231 Clarify "patterns"
- 232 Differentiate our MEPs from underlying protocol MEPs
- 234 Ruleset terminology
- Un-implemented editorial issues
- 226 Cross-binding HTTP features
- 235 Definition of Fault
{Sanjiva questions it}
[.1] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0210.html
Roberto sent comments about them:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0210.html
Roberto: conflict around safe property
Tom: didn't we say that it could be neither true or false?
<sanjiva> +1 to Tom's recollection of this ..
Roberto: that would be equivalent of false
<sanjiva> I also don't care that much but it seems consistent to say
that if the attr is not specified then "no info" is avail
about safety
<sanjiva> So this is a proposal to remove the default value.
Tom: I thought that false meant *not* safe
Jonathan: is there any reason why we couldn't go with Roberto's
solution?
Sanjiva: or we could remove the default value for safe
<pauld> F2F discussion in Cannes:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0038.html
Roberto: yes, but that's what the text says for 'false'
<pauld> thinks it means "known to be safe" rather than "is safe"
David: false means that the operation is not known to be safe
Jonathan: ok; there's still an issue of removing the default value
Tom: based on this interpretation, then I'm withdrawing my
objection
RESOLUTION: adopt Roberto's solution for safe
Discussion of item 2:
ACTION: Editors to change styles from list to set.
RESOLUTION: change styles from a list to a set
Discussion of item 3:
RESOLUTION: make message label property required and make sure it
always has a value
ACTION: Editors to make message label property required and make sure
it always has a value
Discussion of item 4 & 5:
Jonathan: is that a lot of editorial work?
Roberto: no, it's pretty simple
RESOLUTION: accept item 4 & 5 from Roberto's proposal
ACTION: EDITORS to implement item 4 & 5 from Roberto's proposal
Jonathan: I propose to close all the issues marked as such in the agenda
(208 .. 234)
RESOLUTION: Close issue 208 .. 234 as listed in the agenda
Jonathan: 226 and 235 are still open
------------------------------------------------------------------
8. Issue 168: Which operation [.1]
- DBooth revived the thread at [.2]
- Analysis at [.3]
- Umit's proposal [.4]
[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x168
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0112.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0300.html
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0037.html
Jonathan: Originally, this issue looked editorial, and revived the
R114 discussion. Last week, I was hoping to make some
progress, but it seems that we're back to the kind of
discussions we had in Cannes. I have to apologize to the
WG for letting this issue get so big when we closed a
related issue. How is this issue different from the one
we closed in Cannes?
David: Which issue are you talking about?
Jonathan: It looks a lot like the original Operation Name Feature
Proposal. It seems to me like it's reopening the issue,
and we are having the same discussions.
David: Are you saying that the proposals are similar to the ones
we heard in the past?
Jonathan: Yes, and in fact, the objections are the same.
Umit: I disagree. We now have 2 proposals, and we may be able
to solve R114
Jonathan: you are talking about Sanjiva's? I haven't seen much
Support.
* alewis notes that r114 is already solved
* Roberto notes that it isn't
Umit: Several organizations have expressed support for R114
Amy: R114 is already met; it's about being able to, not
requiring, to unambiguously identify messages
Umit and Roberto: I disagree
<jeffsch> There does not appear to be WG consensus on the precise
meaning of R114
Jonathan: How is the proposal different from Cannes's Operation
Name?
Umit: In Cannes, there was a concrete proposal about how
things will look on the wire; the new proposal doesn't
Dbooth: Wanted to point out that R114 would be a pointless
requirement with that interpretation
Glen: Actually, I don't think it's that different; the intent
is the same; the intent is to say that ambiguous
descriptions are bad.
David: I was hoping not to get into the meaning of R114
<mnot> +1 to dbooth's point
<jeffm> +1 from me
David: There are two interpretations; the weaker one means that
it's a meaningless requirement: any WSDL author can write
an unambiguous document
<umit> clapping loud +1
<Roberto> +1
David: I don't think it's productive to discuss R114 here
<jeffsch> s/meaningless requirement/clarification requirement/?
David: The 2 previous proposals that were rejected were: unique
GED and Operation Name; but at the same time, the WG
reaffirmed the need to R114. So I think we are
obligated to consider the proposals to meet R114
DaveO: The folks who wanted unique GED didn't achieve victory.
<jeffm> my +1 was to dbooth's statement that the weak interpretation
makes wsdl meaningless
<mnot> as was mine
<jeffm> wrt to interop
<jeffm> sorry -- makes the req meaningless
DaveO: People are saying that there must be some way to achieve
This. Somebody who voted no in Cannes is also likely to
vote no for the lesser requirement. I don't think that
there is much support being gathered here.
Jeff: I am sympathetic to the way Dave described the situation.
Amy gave her of 6 different ways of doing this. It's
just a situation inviting for profiling, and a statement
that W3C cannot make such a decision. And maybe that's
the agenda of some people here.
* jeffsch doesn't believe that it's helpful to the WG process to
suggest that members have the agenda to thwart interop
<Glen2> Thanks Dave
* Glen2 +1's jeffsch
Roberto: I think that now we are not placing constraints on people
implementation anymore, but making sure that the wishes
of the author are preserved.
* Glen2 ...unless they have hard evidence! :)
<sanjiva> Jeff: can you precisely state how this prevents interop?
If my WSDL has enough stuff for you to send messages to
me, where does it cause interop problems? (Please
separate the case of using WSDL to define standard
interfaces .. in that case its certainly necessary to
indicate how messages are dispatched.) I think that a
lot of people abstained, and are now ready to go for the
new proposals.
<dbooth> There are (at least) two issues:
<dbooth> 1. Whether/how the wsdl:operation name is determined.
In particular: When a service *requires* its users to
support a particular mechanism for determining the
wsdloperation name in order to use that service, should
the WSD author be *required* to indicate that mechanism
as wsdl:required in the WSD?
David: There are a couple of other issues which crept in that
obscured this issue.
<dbooth> Red herring: What is the name of the internal code (or
"operation") that the recipient will execute.
* alewis can't see that the presented issue *is* an issue, since the
mechanism is all in place. what's the other issue?
David: The issue is: who is being required? it's about requiring
the author to mark an extension as required to have the
feature required.
<jeffm> IMO: this is fundamentally an argument about the centricity
(if you will) of wsdl for describing web services and
specifying the contract
<jeffm> Its all about the client
Umit: The point is what you must put in you WSDL so that your
client can communicate with you
<jeffm> Its all about my being able to pick up a wsdl, and build a
client that interops.
<jeffm> I thought this was all about not having to call the server
implementer on the phone, or sign an NDA in order to find out
how to use a service
Umit: What is the requirement on the WSDL author?
<sanjiva> I have no problem with saying that the WSDL author must put
everything needed for the client to be able to send messages
and get the proper responses as the WSDL author intended.
However note that this is just a statement in the spec and
does not transfer to any concrete XMLism for us to define
now.
Glen: I think it's correct that the WSDL needs to say everything
that's required for interaction.
<umit> It does. If there is a mandatory operation, it is verifiable.
Our job is to draw a line between [scribe missed] and
extensions.
<jeffsch> Sanjiva: Do you mean that *everything* must be in the WSDL?
How would we describe co-occurence constraints between
element children, for instance?
Glen: You're going to do something to solve the problem. It's
nice to have a marker to indicate that. Although I don't
want to require unique GEDs, I think that it's a simple
mechanism to achieve this.
<sanjiva> There's clearly a line .. no semantics for example or the
order in which operations must be invoked. I'd like for the
WSDL to capture everything necessary for a single message;
otherwise there is indeed an interop problem.
Glen: We could say that in the absence of any extensibility
indicating otherwise, you need unique GEDs.
DaveO: Have you made that proposal?
Umit: It's in my proposal
Sanjiva: I understand the need to have a WSDL with enough information
to have [interop] to happen. If WS-Addressing is required,
then it's my responsability to specify it. No standard
extension is required here.
Glen: [ explains the proposal ]
Jonathan: I'm still not convinced that it's a different issue from
the one in Cannes.
<sanjiva> Glen, is the proposed new abstract feature required?
Umit: [ explains proposal ]
<jeffsch> Umit, do you understand that there is objection to the
'requirement' for a 'mandatory' extension? It is requiring
the author to add a mandatory extension if unique GED or
RPC are not used.
<sanjiva> I'm -1 to *any* mandatory features .. if we have some
mandatory thing then let's put it in the core component
model.
Jonathan: how about SOAPAction to accomodate that?
Umit: SOAP 1.2 says it's optional. We would be requiring it.
Jeff: Sanjiva, you say you agree with me at the abstract level,
but don't want to force anything concrete. This is what
the proposal is about.
<dbooth> My understanding of Umit's proposal: If GEDs are NOT
unique, and not all operations are RPC style, then the WSD
MUST somehow indicate, as a wsdl:required extension, what
mechanism is required to determine the wsdl:operation name.
Jeff: If you guys don't want to say what is required in the WSDL,
I don't understand why we're here
Sanjiva: I'm not against saying that, but I'm against adding syntax
Umit: I've already toned it down
<jeffsch> In some messaging paradigms, the operation name isn't part
of the agreement between the client and the service. Do
you agree?
Glen: I'm having problems understanding if people don't want
the requirement or not.
* alewis doesn't want the requirement. a number of use cases
negotiate this out of band
David: My understanding of Umit's proposal: If GEDs are NOT
unique, and not all operations are RPC style, then the
WSD MUST somehow indicate, as a wsdl:required extension,
what mechanism is required to determine the wsdl:operation
name. It's not saying how to do that.
Glen: You don't need to mention RPC is there
<sanjiva> I don't think we need to map it to a concrete value for
operation name. I think we should just say "The WSDL must
have enough stuff for the server to figure out what
message interaction the message is intended for."
There's absolutely no need to tie it to an operation
name.
<jeffm> amy -- a use case that negotiates out of band is by
definition, non interoperable
Glen: Second, I don't know how to interpret what you've just
said without a feature URI.
<alewis> jeffm -- it is not, by definition, non-interoperable.
It may be using some other mechanism (a choreography
language, perhaps, or a policy/procedure language) to
communicate. and it may do so interoperably.
David: If you know what extensions you are using, then you know
if you have one that solves the problem
<jeffsch> jeffm: by interoperable, do you mean that each WSDL
processor can construct a semantically correct service
proxy and/or client stub?
<Roberto> "a WSDL document MUST indicate, as a required feature or
extension, the mechanism by which the wsdl:operation
component for a message can be determined"
JeffSch: We have done a lot of work in the WG to implement basic
message paradigms. My concern is that there are message
paradigms other than RPC for which such a requirement
wouldn't be appropriate or reasonable.
<dbooth> But JeffS, nobody *requires* you to write your WSD using
multiple operations. If you are doing so, then presumably
they are significant.
Umit: QNames are used for other paradigms
<jeffm> amy- the use case u describe is using a different language,
WSDL, to describe a web service - no?
JeffSch: in some cases, you don't want to do that
Umit: in which case, you need additional headers, etc.
<jeffm> that's fine -- i bet i can come up with a CORBA IDL->
WSDL/SOAP binding, and it will be interoperable for people
using that CORBA IDL
<jeffm> but its not WSDL
Umit: And then you use an extension
<jeffm> In fact - -that excercise was done many years ago
JeffSch: Not always, they could be depending on the value of certain
fields. It turns out that none of the mechanisms we have
today allow us to describe these situations
<alewis> jeffm -- and your point is? wsdl is not used in a vacuum;
it is, in the particular use cases that I am concerned about,
being used to update legacy systems. there is a limit to
the flexibility of these systems.
<dbooth> q+ to point out to JeffS that nobody *requires* you to
write your WSD using multiple operations. If you are saying
that they are not significant, then why use them? If you
wish to use data values to determine the operation name,
then Umit's proposal would merely require you to *indicate*
that fact in the WSD -- it would not preclude it.
Umit: By requiring such an extension, you will prevent certain
situations to be described.
Jonathan: Umit has a modified proposal
<alewis> jeffm -- and it happens that a variety of tools are used
to complement the information provided in the wsdl, in
order to enable these cases. eventually, things may get
cleaner, but in order to enable the transition, the
ability to describe things, even if incompletely, is
crucial.
<dbooth> My v2 understanding of Umit's proposal: If GEDs are NOT
unique, then the WSD MUST somehow indicate, as a
wsdl:required extension, what mechanism is required to
determine the wsdl:operation name.
Jonathan: I still don't see how it is different from the one in
Cannes, but at the risk of generating more minority
opinions, I will put it up for a vote. I will skip a
straw poll as we clearly won't reach consensus.
<Glen2> as a wsdl:required extension or a required feature
* dbooth has been hearing progress fwiw, but defers to the
chair's judgement
<Roberto> and "wsdl:operation name" means "identifying a wsdl
Interface Operation component"
<dbooth> My v3: understanding of Umit's proposal: If GEDs are
NOT unique, then the WSD MUST somehow indicate, as
a mandatory extension, what mechanism is required to
determine the interface operation component.
<sanjiva> clarification: is this just text in the spec??
<DaveO> this is the same vote as in cannes...
Yes: Lexmark, Rogue Wave, Sun Microsystems, Sonic Software,
British Telecommunications, W3C, Macromedia, Oracle,
webMethods
No: SeeBeyond, TIBCO, Cyclone Commerce, BEA Systems,
Microsoft
Abstain: IBM
Results: 10 Yes - 5 No
Jonathan: Anybody would like to file a minority opinion?
TIBCO and Microsoft may
[Minutes record this: "RESOLUTION: issue 168 closed with proposal
v3" but chair thinks this is incorrect given the following AIs.]
ACTION: Editors to incorporate Operation Name proposal v3
ACTION: DBooth to send email to Mark Baker about issue 168
------------------------------------------------------------------
9. webMethod issues:
- Issue 229: useOperationWebMethod proposal [.1]
- DaveO's proposal [.2]
- Issue 169: Syntax for webMethod - property or attribute? [.3]
- Proposal [.4]
- Atom WSDL binding example [.5]
- Sanjiva's counterproposal (?) [.6]
[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x229
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0288.html
[.3] http://www.w3.org/2002/ws/desc/2/06/issues.html#x169
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0060.html
[.5] http://www.pacificspirit.com/blog/2004/07/05/atom_03_wsdl_20
[.6] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0157.html
DaveO: [ introduces
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0288.html ]
DaveO: the crux of the discussion is about it belongs at the
abstract level. There were also discussions around which
verbs to use; I proposed the HTTP verbs, and I don't think
that it's the heart of the issue.
Sanjiva: You said that this information helps the binding author.
Does it have an impact on the client?
DaveO: I think it may impact dispatch
Roberto: I still don't understand what they mean at the abstract
level
DaveO: [ scribe missed ] Something like the operation safety would
become duplicate information, and I'd like to get rid of
it
Roberto: in the case of safety, we can get an abstract definition;
for POST, it's harder
Hugo: I would like to voice support for this proposal; the
abstract level is the right place, e.g. to have toolkits
use the right settings for bindings supporting the method
advertized; I have made a proposal for meaning of the verbs
that wasn't rejected AFAICT; I don't think that safety should
be removed, as if the semantics of GET don't apply, then I
wouldn't be able to say that my operation is safe
Mark: PROPFIND is safe too
Jonathan: are we fine with this proposal?
<Roberto> does the proposal make the webMethod attribute extensible?
Sanjiva: I believe it belongs in the HTTP namespaces
<mnot> +1
DaveO: I don't consider this as a friendly ammendment
Umit: [ scribe missed the question ]
DaveO: In the case of Atom, they know they're using HTTP, there is
no formalization. My proposal to use the operation name was
(strongly) rejected. Atom has 10 different kinds of GET.
I would be worried to be using the whttp namespace at the
abstract level, as people will consider it weird and
wouldn't use it. We can call that genericMethod, but leave
it in the WSDL ns.
Jonathan: I'd like to extend by 20 minutes
<jeffm> i have to leave now
<jeffm> i wonder if we will have critical mass to make decisions
Sanjiva: I haven't seen a proposal to describe why GET, PUT, POST,
DELETE mean
<Marsh> That't why I'm hoping to deal with more trivial items....
* asir Okay DaveO, I leave my proxy with Hugo
<jeffm> Trivial is in the eye of the beholder
Amy: same comment
Hugo: I have made such a proposal
Amy: I have read your email, it's a nice effort, but it's still
HTTP, it's not generic
POLL = Support for David's proposal:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0288.html
Results: 6 Yes 5 Nos
Jonathan: Any objection?
Umit: Yes
Jonathan: Objection to rejecting the proposal?
Mark, David: Yes
Jonathan: I'll do the vote next week
------------------------------------------------------------------
10. Issue 189: Binding message content to URI [.1]
- Issue details from DaveO [.2]
- Omitting content
- Attributes
- QNames
- ATOM WSDL example [.3]
[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x189
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0061.html
[.3] http://www.pacificspirit.com/blog/2004/07/05/atom_03_wsdl_20
Jonathan: I would like a more concrete proposal
DaveO: I haven't seen any discussion
Sanjiva: I don't like that
Amy?: same here
<Marsh>
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0047.html
Hugo: I like URI construction for other things, but I'm afraid
about the complexity. Attributes and QNames seem complex
to me.
Postponed.
------------------------------------------------------------------
11. Issue 130: Need async request/response HTTP binding [.1]
- WG in favor of adding such a MEP, with some expressing a desire
that this be as lightweight as possible.
- Revived proposal from DaveO [.2]
- Sanjiva's alternative [.3]
[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x130
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0287.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0040.html
------------------------------------------------------------------
12. Issue 211: Omit interface message in binding? [.1]
- Mark's proposal [.2]
[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x211
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0047.html
Considering
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0047.html
Mark: This is pretty much plugging a hole in the spec
RESOLUTION: issue 211 closed by adopting Mark's proposal
ACTION: Editors to implement
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0047.html
------------------------------------------------------------------
13. Issue 236: MTOM/XOP support [.1]
- Details (Umit) [.2]
[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x236
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0038.html
RESOLUTION: Close issue 236 by adopting Umit's proposal
ACTION: Editors to implement
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0011.html
------------------------------------------------------------------
14. Issue 237: Editorial issues with Part 3 [.1]
- Details (Hugo) [.2]
[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x237
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0011.html
ACTION: Hugo to clarify the second part of the proposal (readibility)
ACTION: Paul to research the fault decisions we've taken
ACTION: Editors to implement
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0011.html except
for faults and SOAP binding readability problem
------------------------------------------------------------------
15. Issue 238: Consistent placement of <feature> and <property> [.1]
- Details (Sanjiva) [.2]
[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x238
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0267.html
Sanjiva: they're not consistently at the end
Roberto: I think they are. They should be at the end
Jonathan: we need to clarify this
ACTION: Roberto to check if <feature> and <property> placement in
the infoset representation prose is consistent with the schema
------------------------------------------------------------------
16. Issue 239: Part 1 Editorial Issues [.1]
- Details (Asir) [.2]
- Already implemented.
[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x239
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0110.html
Jonathan: it's been fixed already; any objections?
RESOLUTION: issue 239 closed
------------------------------------------------------------------
17. Issue 240: input serialization flexibility [.1]
- Details (DaveO) [.2]
[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x239
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0073.html
Jonathan: the WG did agree to allow some text like proposed to go
it. Any objection to David's wording?
RESOLUTION: issue 240 closed by adopting DaveO's wording
ACTION: Editor to include DaveO's wording:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0073.html
------------------------------------------------------------------
18. Issue 241: AD Feature: HTTP header conflicts [.1]
- Details (Hugo) [.2]
- Roberto's suggestions [.3]
- Consensus on "say that it is an error if the HTTP stack finds itself
having to override an AD-specified header"?
[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x240
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0131.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0148.html
Jonathan: the proposal that seemed to carry support was to have an
error in case of conflict
RESOLUTION: issue 241 closed by raising error in case of conflict
ACTION: Editors to indicate error for AD HTTP binding in case of
conflict
------------------------------------------------------------------
19. Next steps
- Closing issues list on Parts 1, 2, 3 except to editorial issues.
- Last Call Schedule:
- July 22nd (90 min telcon):
Editors complete editorial work for WG review.
Disposition of any outstanding editorial issues
- July 29th (short telcon):
Approval of Last Call drafts.
- Aug 3rd WSDL 2.0 Last Call publication.
ADJOURNED
Received on Thursday, 15 July 2004 18:59:08 UTC