Working Group home page · Meeting records
Present
------------------------------------------
Apple Mike Brumbelow
BEA Dave Orchard
Boeing Gerald Edgar
CA Igor Sedukhin
ChevronTexaco Roger Cutler
Compaq Kevin Perkins
Compaq Yin-Leng Husband
Contivo Dave Hollander
CrossWeave Timothy Jones
DaimlerChrysler Hans-Peter Steiert
Daimler Chrysler Mario Jekle
Digital Island/Exodus Joseph Hui
EDS Waqar Sadiq
Ericsson Nilo Mitra
HP Zulah Eckert
IBM Heather Kreger
Intel Sharad Garg
IONA Steve Vinoski
Ipedo Srinivas Pandrangi
Macromedia Glen Daniels
Microsoft Allen Brown
Microsoft Henrik Nielsen
MITRE James Davenport
MITRE Paul Denning
Nortel Abbie Barbir
Oracle Jeff Mischkinsky
SAP Sinisa Zimek
Software AG Mike Champion
Sun Chris Ferris
Sun Doug Bunting
Sybase Himagiri
Systinet Anne Thomas Manes
W.W. Grainger Tom Carroll
W.W. Grainger Daniel Austin
W3C Hugo Haas
WebMethods Prasad Yendluri
Regrets
------------------------------------------
DISA Marcel Jemio
HP Dorothea Beringer
Nokia Michael Mahan
Planetfred Mark Baker
Not Present
------------------------------------------
Cisco Sandeep Kumar
Cisco Krishna Sankar
Documentum Don Robertson
EDS Mike Ballantyne
IBM Jim Knutson
Intel Joel Munter
IONA Eric Newcomer
Ipedo Alex Cheng
Macromedia Tom Jordahl
Software AG Nigel Hutchison
Sun Mark Hapner
Waveset Darran Rolls
See agenda posted by the Chair.
Jeff, Oracle - discussion on WS/Description WG about use of object
references in that group. Get that on our agenda?
Chris, add just before item 8 above ("mission statement")
No objection to approving minutes from last week - Approved
None.
WS-CG met this week, mostly talked about Technical Plenary and
proposed Web Services session (1 hour), may discuss re-chartering
- Q&A may include some discussion of each area eg. "What is a Web
Service?"
- Jeff Maginsky will represent our group at this Plenary, Chris will not
attend.
- WS-CG did not discuss liaison work with outside groups, did talk about
relationship to Semantic Web work.
Editing team (Daniel Austin): Now have a team in place
Editing team, Chris and Hugo met twice this week. Result is the
Requirements document. Hopes the issues with access to this document
have been resolved. Issues:
- Some errors and typos
- Some problems in naming conventions
- Basically, very date-driven towards providing a stake in the ground
- Started from Daniel's numbered goals, Mike Champion's definition of a
web service, a few other things (eg. goals from the list), general
outline of the final document with lost of empty space.
- Plan to update the document weekly as we move towards F2F.
Hugo: Use CVS variable to generate a date for the document. Not a W3C
working draft, an internal document. Remove "Working Draft" nomenclature
for now.
Chris: Some experience with XML-P working group drove his comments.
Daniel: Let's take this off the call and handle out of band.
Thoughts on this Requirements draft? A few people hadn't read this
document.
Chris: Working to keep this group's efforts publicly available (operating
in full view as much as possible). Avoid complains (as occurred with
XML-P) that might arise from hidden processing.
Chris: Anyone have problems with making this public with many caveats?
Doug: Though I haven't read it, see no problems given the many caveats.
Daniel: Delineated the many caveats in the document.
Paul Denning: Assume we remove the "Working Draft" words as described
above.
Dave Hollander: What is our intent in doing these publications?
Chris: Would like to keep it as up-to-date as possible.
Dave Hollander: Is work group approval necessary for each later
publication?
Chris: Let editors publish when they wish, don't review every version.
Prior to F2F, everyone in group should do thorough review (of a frozen
version) to allow people to bring their comments to the F2F. Give W3C
members ability to participate in Requirements discussion.
Dave Hollander: Ensuring this won't a substantive decision going forward,
avoiding issues with delays and group members' review time.
Jeff Mischkinsky: Will it be a working draft after F2F?
Chris: Yes, following the F2F should have resolved the issues, one last
round of editing to match those resolutions, then will vote to make it an
official Working Draft.
Jeff Mischkinsky: Should this roadmap be in the preamble.
Chris: Hugo, is that appropriate?
Hugo: We can put whatever we like in the document, fine to work towards
this roadmap.
Daniel: Required by W3C Process to have everything for F2F available 1
week prior to that date. 1 April will be final publication before F2F.
Jeff: May want to ensure we get all comments in prior to 1 April.
Hugo: No requirement to solicit public comments prior to first "real"
publication. May be better to wait until it's a real draft.
On the other hand, no reason to hide from the public. In our charter to
operate as publicly as possible. Welcome comments though we don't
solicit them.
Dave Hollander: Great sentiment: Put into the document enough information
that reader can understand the current status and set future expectations.
ACTION: Daniel Austin to add suitable text describing this overall
intent (not specific schedule) to the document.
Chris: Any other comments on this?
Nilo Mitra: Comments on document or its publication?
His comment (sent via email) was only on the document and shouldn't
prevent publication.
Chris: Anything else before we make it pseudo-public, linking it from our
public web page?
Chris: Hearing none, will go ahead.
Daniel: Will change permissions.
ACTION Daniel to change permissions on the draft
(he'll mix that with above item and some cleanup).
ACTION: Hugo: Will add link from our public home page
6a) Jeff: Point about Web Services Description WG issue dealing with
object references. Some in that group thought our group should be
deciding their scope.
Waqar: Thought issue centered around service reference. A fundamental
issue rather than a pure description issue (life cycle). Thought
underlying model had to exist before it could be described. Will be
handled from a Description point of view later. How do we see them
working?
Daniel: Is it odd to have Architecture running in parallel?
Dave Orchard: No reason to hold up work in the other groups. Very
comfortable with other groups working in parallel.
Waqar: Also came up during XML-P requirements gathering. Certainly an
issue that doesn't just get handled in one WG. A fundamental issue our
group should address.
Chris: Doesn't want to solve the problem on this call.
Waqar: Get feedback from this group. Start the thoughts around this
issue. Solicit feedback.
Chris: Question really raised is "how to handle tracking of issues
raised in other W/S WG's?" Can't solve this on the call, how to fill
this hole in our process? Should we start an issues list immediately?
Is this an issue?
Dave Orchard: Definitely should be tracking issues from other groups.
W/S Architecture document should resolve these issues as possible.
Should also prioritize these incoming issues against requirements and
use cases. Need use cases and requirements to handle this issue; a way
to flesh out those use cases and requirements. Our process at the end
of the day: Doing a bottom up architecture document as we attempt to
answer these questions.
Jeff: Agrees with David. Adding concern about other groups waiting for
us to address this problem. WSDL has an underlying architectural model
of the world, shouldn't be asking us to define the same thing. Let
them attack these problems. We can react to anything concrete they
come up with; they can react to something concrete we produce.
Chris: How to express the issue? For example, should object references
be a requirement for Description WG? May be better for those groups to
provide use cases to us.
Dave Hollander: Dave Orchard correct. Should only extend this to tell
outside groups very quickly whether or not we'll address the issue.
Don't leave it in the queue, would be destructive to the process.
Daniel Austin: Let's decide how to deal with the issues list?
Discussion seems to lead us to a rather large overlap with the
Requirements document.
Chris: Concerned we'll end up answering questions instead of defining
and architecture.
Dave Orchard: What would be the downside to answering questions?
Chris: Main issue is not getting an architecture out. That
architecture should answer the questions.
Daniel or Dave: Some group to prepare things on behalf of the
submitters. Maybe, set up another sub team.
Dave Hollander: Schema WG assigned 1-3 members of WG to each response.
Feed back response along with (possibility) of outstanding rejections.
Chris: Not necessarily a fixed team?
Dave Hollander: At one point, just went around the room.
Chris: Will the editors take this up?
Daniel: Would like an additional resource to maintain the issues list.
Dave Hollander: Will join the editors team to handle the issues list?
ACTION: Dave Hollander to start an issues list.
Chris: Process that includes feedback to submitter, requesting use
case.
Waqar: Likely to have use cases fleshed out within the submitting
group.
Dave Orchard: Notion of use cases is crucial. Request submitting team
to refer their issue to our existing use cases or to suggest expansion
to our set of use cases.
Dave Orchard: Since we don't have any use cases yet, get the ones WSDL
group has.
Jeff: Make sure WSDL group doesn't wait for us. Make it clear we don't
expect that of them. Make sure they don't think this is a WSA issue
and have that block them.
Chris: Let them know almost immediately and provide them our priority.
Waqar: Agree in general. However, some problems are architectural and
any WG solution (which might be superficial) will impact other teams.
Avoid hacked up solution.
Dave Orchard: Deal with architectural issue in same way company
architects do it: Tell them to go ahead with hacked solution, may come
back later with a better solution.
ACTION: Dave Hollander Will draft a process for handling issues of
this ilk.
Chris: 25 minutes left, went way over on this last item.
Chris: Start the discussion, so that we have a strawman for the Plenary.
Has seen some comments from Mike, Dave Orchard and Heather.
Dave Orchard: Should define web services as a subclass or subtype of the
web "if you will". Something that fits inside the web. Some may think
of web services as something more than the web. Take a general
definition of the web, loosening data type and protocol issues, then
define web services in terms of this definition. Some refinement that
mentions SOAP, WSDL, et cetera would be appropriate.
Roger: Response to question was silence. Impression web services are
something that exists at one point in time. Suppose you have a
purchasing system that's not a web service. Is a web service one of
those components that's part of this system?
Daniel: Introductory document includes Mike's strawman. Pretty well
meets Dave's discussion. Start with that and refine it. Add "thingie"
to the glossary.
Chris: Also, add "do-hickey".
** Action item for Dave Hollander?
Waqar: Defining web services for our group in particular. Definition
should / must include other activities such as WSDL and SOAP (other
activities in this group).
Anne: Orchestration versus services question Roger raised. Services are
components that are contained within an overall orchestration. Don't
describe the orchestration as a single service unless it is used in that
fashion. Choreographed system not a priori a web service.
Dave Orchard: Likes inclusion of web service as a descrete thingy: A
single resource. Fits in well with the web architecture description of
an identifiable resource. Avoids some issues with web service as a
collection -- say it isn't from the start.
Henrik: Follow up on David's point. Important that we don't do top-down
definition. Good to start without a lid, limiting how far we can go.
Have the first components being worked upon. Huge amount of space in
WSDL and SOAP that can be filled out.
Steve: Disagreeing somewhat with Anne's definition. No reason to limit
web services only to things not composed of other web services. Special
thing about web services is its support for application to application
integration. Inclusion of orchestration, choreography and semantics will
be very important.
Chris: Queue getting too long. Are people comfortable settling rest of
issues on the list or deferring 'til next week.
Dave Orchard: Respond to Steve on orchestration. Likes web service being
a single thing. Hard to give resource identifier to a larger
orchestration. Need to be able to couple things into web architecture.
Waqar: Perfectly legitimate to package an orchestration as a web
service. That orchestration provides a single service externally. Can't
be rigid about it.
Igor: What is web service? Losing important points about business
metadata that may exist around the web service. Meaning of the process
is what's important.
Gerald: Back to Anne's desire to have web service as a single object. Go
to web page that may include objects drawn from multiple places. Can
layer architecture to not include orchestration by default.
Anne: Web service that sends things out to other services very different
than ebXML concept of collaboration. "What I'm going to do after you do
something." Task uses a number of different resources.
Sharad: Should look at web services in a broader aspect. All of our
discussion has focused on commerce use cases. Think about general
provision of shared resources on the web.
Hugo: Emphasize David Orchard's point. We really must identify web
services by URI. If URI web services disappear, we're in trouble.
A few people: Yup.
Chris: Will compile this and present to the group. Tentative position in
Jeff's presentation.
Daniel Austin: Pointing to goal 15, a point made by Dave. Dave Orchard
like's it.
Pointing to goal 16, a point made by Anne.
Waqar: Original submission used the word "functional", should that be
added again?
Daniel: Added it back.
Pointing to issue (1a), a point made by Dave Hollander. A potential
replacement for goal (1)? Please discuss on mailing list. Wants to nail
this one in particular.
Dave Hollander: Please remove my name here.
ACTION: Daniel Austin: Will remove your name and Mike Champions from the
document.
Chris: About out of time. Useful though we didn't cover last issue. Will
have a meeting next week in spite of number of people in Cannes.
Recommend those in Cannes seek a central location for teleconferencing
into the group, might need to request something from hotel.