2) Minutes were approved.
3) Discussion of the XMLP issue.
From the push back on we saw as their issue. Did we get a response?
Mike Champion sent a revised version - received comments in return, but no chance to incorporate those comments. Generally the sense of the discussions, it is ok, but not clear.. (action item - to clean it up before next week)
4) Discussion about start and end times of the January Face
Initially there was a proposal is to have a few hours of overlap in the morning Wednesday
There was a proposal to start officially at noon, but be available at ten for joint sessions with the description group. no objections were voiced. Finally, there was a question on when people need to leave.
People expressed a preference for leaving early Friday. Intent to end before 4, and one voiced the need to catch a 2 PM flight. Question on if people object to starting at 9. The joint time would be determined later. Comment on if the joint work would be in the morning. Usage scenarios would be a candidate joint work item.
The for the January Face to Face will start at 9 AM Wednesday to end noon Friday.
5) Question for the management task force
For the Management task force (MTF) - is there anything to bring to the groups attention. They said they have not yet had a change to discuss what are the components of management. There was a question if this was too detailed for architecture. The MTF should figure this out, Heather and Hugo are to discuss this. Hug was reporting to Heather that the work may be too detailed and there is a need to stay at the architectural detail. The working groups concern that this groups effort was too detailed. Heather will contact Hugo on this. Question on if there is anything in the e-mail to address. The response was no- not at this point.
Issues list: sent to the editors, but not posted publicly. There were questions on if there was a reason, or if there was simply a problem in posting it. Tom Carroll sent an e-mail to the editors about it's review.
6) SOAP Features / Extension framework status
On the issues list, Mark's issue of limited number of methods.
Mike asked- does anyone want more time? or can we just resolve it? Mike proposed that we were not inconsistent with the web architecture.. The architecture articulated by Roy Fielding not a normative constraint or principle of the web. One speaker suggesting that we do not intend to look more carefully into this at this time. This is an issue for the TAG. A bit more background: the tag does not have enough time to address this. If an individual raises an issue – this is not addressed at as high a priority as what is raised by a working group. The question is the TAG the appropriate venue for this issue? There was a question of typing and abstraction. We use sockets as our interface. For the architecture document extract what applies. The architecture in its present form is get, put and post, but that we need more. Web services are about typing. If you call something a method or if you call something a type, it is equal in complexity.
There are three options:
1) do nothing as we go thought the issues list..The suggestion is that we provide a technical response, but at the same time not spend too much time because there are other issues to resolve. David Booth commented that get/put/post is not enough. If there is no benefit in continuing this discussion – from one speaker's comment Mark may be fine with any kind of a response. If we do not want this left open, just respond and close it.
2) provide a technical response
3) a procedural response.
A) A polite note to say we do not feel comfortable closing this because it is not in the documentOption A carried….
B) close it and discuss the wording.
Katya made a comment: to spend a little time to close it to be able to but this issue behind us.A still carries.
7) The web services description group requirements
Does anyone think we should have a group response?
Frank: it would be good to have a group response. This has architectural implications.
Hugo: this is appropriate to look it over and bring up architectural issues to our attention.
Hugo proposed to make a one minute summary. This is accepted.
Hugo: on the web http methods have a clear meaning it would be a good idea for WSD if should use the web methods feature. People kind of agreed and started to stay that it would be interesting for choreography if the item was important, for reliability. Add this to description. Does this fit into the description . does WSDL and SOAP aligned for web methods. Hugo was not sure of the wording, but the description of the web methods was important in this. Mark Baker was involved. Architecturally this is an aspect of the description. But they were uncertain of the form to use. A suggestion to add to WSDL 1.2 to express in their description on the importance or reliability of the service. Is this appropriate for the specification. Need to reconcile SOAP 1.2 with WSDL 1.2 but not get too far into the safeness or idempotence is beyond the scope of this. It is their responsibility to support soap 1.23 the web methods feature was Hugo’s thoughts on idempotence and safeness. One way to describe it was just to describe the features. there may be a need to inherit it from the HTTP level. Web methods have been done, and to address web idempotence in the same way. As was discussed in the e-mail. When you are forced to use POST, the service may still be idempotent Idempotence was discussed as far as how it applied here. To establish it at the SOAP level and have WSDL reflect the SOAP. For post there is a need for additional information needed. Does the most current version of HTTP use reflect idempotence? He is not as persuaded that it is a requirement for WSDL.
Hugo does not think we are ready to comment on the requirements.
There was a comment that we need to get our draft done. We would like to provide a response, but no one is stepping forward to go though the WSDL document and bring up architectural issues to the group.
(Action item) We are encouraged to go though the WSDL draft and bring up issues to the group.
Hugo: in order to not loose "idempotence" we will draft a response and send it to the issues list.
8) Discussion about the two major threads in the e-mail
list reliability and semantics. Primarily by Frank Katya
Both of these are items for the working group to address.
Summary of the discussion: there was confusion that the WSA should address the semantics issue.
Dave Hol.. Said we should not address this ourselves. this may be a new working group.
Frank: This was a useful discussion of semantics, and to potentials start a working group. There is community support to doing something in this space. It is too early to create a new working group. There is no charter at hand to use. We should continue this discussion at the F2F. (other comments?) this working group does do semantics. But is there willingness in the community as a whole. For this. To draw a box around semantics. Picking up on WSDL, it is not mentioned there at all../ we have to fit semantics into the Architecture. we have a first stab, but we need to revisit that. We need to have a language to do that. what are the semantics written in. ?
Katya about DAML and other European effort for semantics – a meeting in Innsbruck with two subcommittees, semantics and language. For those interested, contact Katya. One connection seen – the activity is already started (larry bird DAML project) this effort may result in a note to the W3C ??- owl language. May result in this being brought into the W3C not under any standards body at this time. Comment on a pluggable semantic architecture. If is possible to define a pluggable architecture we may defer to other work to define the actual mechanisms. …. The answer is yes in tthat how semantic web fit into web services is part of our work. As far as pluggable architecture, that is the intent. Currently there is not credible of a specification of a language that can be used to describe web services, there is research, but not anything concrete. WSDL is not the semantic description.
There was a question on procedure: we have two roles- to build the specifications, and to charter working groups. This is a fair amount of work. What should we do to address these desires – a task force to look into this, or what? What should be the next step. The task force may be a good idea, but people were not sure at this point.; there was uncertainty about starting up a new working group – but to at least establish a liaison with the existing groups. What should the WSA do to track these semantic discussions… Frank Katya Mike (chair)
Other issue: reliability- has that discussion gone anywhere? Are
we near resolution? We need to capture issues on reliability. How
difficult is it to provide a real solution? We have not documented
this very well. To look at ebXML on this and To read it as a
reference to existing work. There was a suggestion to have this at
the face to face. There was a question on if they would accept
this.; This was discussed in the XMLP – there might be
light-weight issues to address. Is this a lightweight issue
they would address? There is an architectural issue on where
reliability fits in. is may be protocol or in choreography. This
may fit into the message exchange pattern, but other portions fit
into orchestration. The intent was just to bring this op to make
people aware of this.
(action item) Request to have a summary of the major issues raised in the mail exchanges regarding reliability - . Roger and Eric are to do this
Action Item Summary:
We are encouraged to go though the WSDL draft and bring up architectural issues to the groupChair: Mike Champion <firstname.lastname@example.org> Scribe: Gerald Edgar
Request to have a summary of the major issues raised in the mail exchanges regarding reliability - . Roger and Eric are to do this