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
to 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
document.
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
Mike
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 <mike.champion@softwareag-usa.com> 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