Working Group home page · Meeting records
See agenda posted by the Chair.
Face-to-face?
Chris: Krishna's not here, trying to map out F2F schedule for next few months.
MINUTES APPROVED
ACTION: DanielA: post issues list into CVS repository and post pointer to it
- WS-CG report
No meeting this week, postponed until hopefully next week.
- Editing team report
Daniel's report:
Met Wednesday.
Comments list started. Getting new issues editors on board.
Discussed current doc.
Timelines for getting things done.... working backwards from
publishing at end of April.
Apr 1 publish for f2f, second publishing cycle on Apr 15, followed
by comments cycle and hopefully publish draft at end of April
Editing tasks were divided up
Chris recaps the story so far. Slight differences from version in the
req'ments doc.
Prasad: what is the real purpose of answering this question now? Is
it premature to answer this before we go further defining the apects
which shape the architecture?
Chris: the intent is to have something that's reasonable ("close
enough") to put in the req. doc, which will be revisited later. It's
a work in progress.
Eric: It's important to keep going, this is fine for now.
(various +1s)
Jeff: Once this is done, you can almost throw it away...
Daniel: Disagree, this will help us a lot, but we're done with it now.
DaveO: URIs are in the definition now, this is good. There's been discussion,
and that's good. Also, people have reviewed the charter, which is good.
Comfortable with moving on, though there are a few tweaks I'd make.
Chris : POLL - any objection to publishing this in the req doc as a
working definition?
Suresh: delete the word "direct"
Glen: change it to "programatic"?
[some discussion, ending with Suresh removing his objection for now]
NO OBJECTION
ACTION: Editors: include definition of web service and make it clear
that it is an interim working definition and may change over time
Chris summarizes the situation.
Chris: Any objection to incorporating these?
NO OBJECTION
ACTION: Editors: include glossary definitions
Chris : We should be assigning champions to the various goals we have,
members willing to drive discussion on these issues forward.
(discussion - March 4th editors draft is current)
Mike: I feel rather fated to be a "Champion" (:)), so I'll volunteer for 5
Dave O: Volunteer for 10
Joe : #6 (security)
Daniel : #2 (modularity)
JeffM : #1
Daniel : #1A
Nilo : #3
Abbie : #4
Suresh : #7
TimJ : #8
MarkB : #9
MikeM : #11
PaulD : #12
Hugo : #13
DougB : #14
DavidO : #15
Yin Leng : #16
Champions should:
Review what the goal currently says, start a cleary ID'ed email thread
which asks for discussion around each of these goals, collect feedback,
present proposal at next week's telcon
Dave : post status by Tuesday so it's easy to find?
Chris : Will generate agenda after getting these
Doug: How do we resolve crossover between goals?
Daniel: Don't worry about it until we've got things better defined, and
we know what the overlap is more precisely.
(discussion of formats)
Daniel : Let's publish in HTML.
ACTION: DanielA: Post HTML of current requirements doc by EOB today
ACTION: ChrisF: Annotate requirements document with names for each
goal (see earlier action items)
Chris: let's try to hash these out a little here
- DAG0001 - reference framework (see thread at [8])
Chris: This should be 1A, I think
Dave : basic idea is framework where we can build assurance, but not
define assurance ourselves. We provide a well-defined enough spec that
you can build a conformance suite around it - shouldn't be underspecified.
Daniel: If we define a reference architecture, it's for defining conformance.
Dave : shouldn't force action for non-conformance
Daniel : +1, "assure" is too strong a word
- DAG0005 - simplicity and ease-of-use (see thread at [9])
Mike: this is not unacheivable, despite discussion to the contrary. As
Tim Bray has pointed out, even though it might be hard to define, it's
useful to have in there. Re: ease-of-use, can't see how a ref. arch. could
control ease of use of products
Roger: Two different "simplicity" metrics, and we get mixed up between the two.
Architectural simplicity, then simplicity of use of the web service. both are
relevant.
Chris: new "ease of use" goal, separate from "architectural simplicity",
w/Roger as champion?
?? - Two classes of user - people reading the doc, and people implementing web
services. Should make life easy on both.
Mike: Let's definitely not drop it as a goal
Glen : 3 classes, spec writers, implementors, and end-users
Mike: dealing with the first two, not the last
?? - end-users should be able to use + compose web services
Dave H : this is a deep subject, defining the user. Let's not go there until
we've done the drilldown...
(discussion ensues)
Mike : will draft a more detailed statement, and send it via email
- DAG0006 - security (see thread at [10])
Joe: Need to define what aspects of security are important. Trust model
is critical part of this. Privacy is also important, we need to define that
as well.
Yin-Leng : Message vs Transport layer definition?
Joe: Message layer = XML messages, for instance XML DSig. Transport level
is IPSEC, HTTPS, etc.
(will discuss more via email)
- DAG0010 - using XML Technologies (see thread at [11] and [12])
DaveO: Our charter says our stuff must be XML based.
Mike: Does it really say we must use XML, or just use it where appropriate?
DaveO: It's clearly a goal that we use XML. Might be cases when we
can't/won't, but it's a goal
Mike: We should use it to the greatest extent possible within the limits of
good sense.
DaveO: We're trying to describe what we're targeting. With each of
these goals, there certainly may be cases where we can't meet the
goal.
Henrik: "use XML technologies" means we'll look at, but not define, these
technologies?
DaveO: exact pieces will be filled in by other WGs, but the goal is for the
architecture to be based on XML
Daniel : binary objects are cases where it might not make sense
DaveH: goal to invent no new syntax?
DaveO: We can't meet all the goals at the same time. I'm comfortable saying
"we shall use XML", and we weigh tradeoffs between the goals and the
requirements.
Joe: Should use XML except where we can justify not using it, i.e. transport-
level security.
----
Chris: Let's aim to finalize goals by next call.
See also the list of pending action items.