See also: IRC log
SeeBeyond Ugo Corda
Chair: MikeC and DaveH
Scribe: Meeting canceled 2002-12-26 and 2003-01-02 due to holidays.
Scribe: Minutes approved: http://www.w3.org/2002/ws/arch/2/11/2002-11-07WSAWGminutes.htm
ChrisF: Two problems: inadequate explanation and might need to
... They responded that they didn't see the need for more use cases, and the other aspect was out of scope.
... I gave a concrete example of what I conceive to be a typical use case that crosses a trust boundary that requires saving representations of the resources (such as in MIME multipart) so when the receiving end receives the message, they could just get the URIs.
... I sent this to the list, DaveOrchard +1'ed it.
... A proposed response to reconsider.
... Sent early this afternoon to member list.
Frank: Anything new in the response?
ChrisF: No. Just editorial changes.
... This explains why we're unhappy and gives a concrete example of a use case.
MikeC: What exactly do we want them to do?
DaveO: Whether they choose to use the material, the use case that we're providing illustrates the issue.
ChrisF: The use case is trying to establish a way that DaveO and I
think the attachments should be handled.
... It allows the app not to care how the attachments arrived.
Frank: It seems to imply that a Soap message is a mini-portable-cache. Will this require a lot of hard thinking on their part?
ChrisF: I hope not.
... i was on the Attachment TF before I left the WG, and I think a few of them looked at it the same way.
... I was surprised that it wasn't written up that way in the end.
... There's no mention of having a reference to them from the message itself. It's just a bad job in my opinion.
MarkJ: I think I was there. It wasn't discussed in much detail.
... The assumption is that the binding could do what you're describing.
... We didn't want to prescribe or assume any particular mechanism.
ChrisF: Then I think the Feature doc is meaningless.
DaveO: I don't think it makes sense to deal with attachments
without dealing with references to them.
... I looked at this as somethign that will be used in follow-on work. Not as a proof of concept.
MarkJ: Yesterday on the call there were a number of people who were skeptical about the value of this abstract feature document, and there was a decision to delay it in the rec track and decouple it from the other doc. There was a feeling that it needed to be better proven.
Doug: I'm completely in agreement with both ChrisF and DaveO. If the XMLP WG ignores the use case that ChrisF describes in the abstract document, then they'll have no incentive in the concrete document.
DaveO: I have a very similar concern.
<Daniel> Daniel AUstin has joined the call - sorry I'm late!
DaveO: There's a concern that this will be perceived as increasing the scope, when we think it's been in scope all along.
Hugo: The first sentence sounds very confrontational to me.
ChrisF: It was meant to be a pushback. We want to make it clear that we do not accept that response. Do you have a more appropriate wording?
Roger: I think the verbiage is over the top.
Scribe: (Discussion of possible new wording)
Suresh: What extra flexibility are we getting by not having a specific syntax?
MarkJ: Some URI addressing schemes may be better than others for
different use cases.
... Rather than prescribing one-size-fits-all, it was left open ended.
Suresh: So you don't want a document-centric binding?
MarkJ: Unlike referencing objects on the Web, the binding takes the place of the DNS resolver in the case of messages.
Suresh: I agree. The WG should strive for solutions that solve general cases.
MarkJ: There are two hats we could wear in responding.
... Just as people who are responding.
... Or as Arch WG saying "There's a real WS arch problem, and you need to solve this", and I think we have the authority to do that.
Daniel: A third possibility is that we respond as a peer WG.
... W3C WGs need to be consistent with other WGs.
... That third hat sounds less authoritarian.
... But its a strong argument.
MarkJ: We might say we'd like the concrete spec in conjunction with the abstract spec to consider the following use case.
DaveO: When I look at the issue of references and attachments and
URIs, it feels like I'm wearing an architecture hat.
... I strongly feel that the issue of references is very much architectural.
<hugo> DavidB: Agree with DaveO
<Roger> Could you post a link to this email again? The draft we are discussing?
Suresh: Does the proposal have a concrete binding?
ChrisF: It's totally abstract.
<Roger> Oh, never mind. I just realized it's on the private list.
dbooth: I agree with DaveO. It's an architectural issue. References are the most fundamental part of the Web architecture.
ChrisF: I suggest that we follow the proposal that Hugo made to the list.
Scribe: Hugo's suggestion: http://lists.w3.org/Archives/Member/w3c-ws-arch/2002Dec/0018.html
... ACTION: ChrisF to redraft the response to XMLP again for WS Arch WG to review again next week.
Zulah: HP had some issues with the level of detail we were doing in
... Our understanding of the goal of the WS Arch WG was to propose new WGs.
... HP felt that we should understand what work needs to be done, communicate that to the Arch WG, and then propose a WG.
... That was not a popular view in the rest of the MTF.
... There was desire to continue to work out more details. HP was in the minority.
... of the TF.
MikeC: Have we learned enough about Mgmt to propose a WG, or is
this still all architectural stuff?
... The way I understood this from a few F2F's ago, we were doing the arch work, and an OASIS group was doing the spec work.
Zulah: It's not clear how formal the liaison relationships are.
... The OASIS group was not necessarily a spec based on the architecture. They're doing their own thing. They're using WS interfaces for mgmt.
... So that connection between OASIS and the arch group has not been made clear or formal.
Igor: I think the decision was to go into the details, and then
later we'll decide where they should go.
... Until there is concrete work to discuss, we should not bother the rest of the WG.
Zulah: I think we worked out an agreeable approach.
MikeC: So you'll proceed until the next F2F, and then we'll review.
Hugo: There were two approaches: (1) Go into details and then find
a framework to fit; (2) Find a framework first.
... But the charter of the Arch WG does not include going into the details.
Roger: I get all this email and read it and it seems like there's stuff going on that I don't know about.
Zulah: Some of the email goes to the public list today. (I sent some to the private list yesterday because I didn't know if it was airing dirty laundry.)
Roger: Is there a third list? I feel like there's something going on that I don't know about.
ChrisF: I too share concern about the level of detail of what would
go into what we publish, though I don't have trouble going into detail in
order to figure something out.
... I was willing to explore that level of detail, but that we need to decide what level we want to publish, but it would more likely be at the framework level.
Hugo: I agree with ChrisF.
... But on another topic, I have sent mail to the MTF to remind them to use the public list.
dbooth: The W3C Team previously expressed concern about the MTF,
partly because of the longevity of it. There was concern mentioned in the
team that a TF is for a larger action item.
... Long term work is what a WG is for.
DaveO: I have no problem with the length of the WG.
... I lean toward relying on the TF to let us know when they're done with their arch work.
... Arch groups will often work up fragments of syntax to explore an issue.
MikeC: We'll continue at the moment, and then decide what to do at the next F2F.
ChrisF: No progress since the F2F. I carved out the relevant sections from the Soap 1.2 WD.
MikeC: So we'll have another week to read ChrisF's draft and make suggestions. Then next time we'll address what we want to do.
DaveO: I like what might happen with this work.
... I look at this as the first vapor-person proposal.
MikeC: I think this could be an important contribution to the Arch WG.
Tom: I've almost finished updating the issues list.
... But I need to finish separating out the "substantial" from the "editorial" issues.
MikeC: What should we address next? Management? Reliability? Others?
Frank: That's a dangerous question!
... What about semantics?
MikeC: Another way to frame the question: Are there issues that we could drill down deeply enough into that we could have a substantive discussion of forming a WG at the F2F?
Frank: The idea of WS having semantics, and then expressing requirements that are incorporated into the architecture, needs to be addressed at some point.
<Mark_J> A call from the XMLP chair for new work items -- http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2002Dec/0018.html
Frank: Another aspect is to address the relationship between WS and
Semantic Web, and how to integrate.
... Reliable messaging might be another WG we could spinn offf.
Colleen: Do we automatically spin off another WG when we identify the work?
MikeC: The Choreography example is a template for what we need to do.
MarkJ: I posted something to the WG asking for work items for the
XMLP group to pursue.
... There may be another alternative to the heavy weight process. If we coordinate with that group, then they may be able to start up some work if it's on their plate anyway.
MikeC: So Messaging for Soap is plausible for them to pick up, but coordination with Semantic Web might require a full fledged WG.
DaveO: I like the idea of coming up with small scope work that the
XMLP WG could do.
... But there might be work that members would not want to do in XMLP.
... I suggest that our chairs talk with DavidF first to get a feel for what they might take on.
Ugo: A big item that came to my mind was Transactions. It's not clear that it would be tackled as part of Choreography.
Martin: It's out of scope to talk about transaction protocols, but we could talk about it in this group.
Roger: If you're talking about adding reliable messaging, then how does the IP work?
Hugo: If something is out of scope for the WG, then the scope needs
to be extended, and it is covered by the IPR, but the members need to
resubmit their IPR declarations.
... The current proposal was to extend the life of XMLP WG but not change its scope.
... To have some life after Rec to deal with errata, etc.
MikeC: I suggest others with idea (such as Frank) to try some email on the list and see what interest evolves.
Frank: Part of the problem is that the most of the semantics people don't read the Arch mailing list, so we won't get the right audience by discussing it on the Arch list.
MikeC: But we need to understand it.
Frank: True, and I'll work on that.
MikeC: There are lots of possibilities for involving people.
Roger: I'm very strongly supportive of the reliable messaging
... I'm glad to seen an intro on the list to the ebXML stuff.
<Daniel> bye all!
DuaneNichull: The ebXML spec was based on a wide variety of needs.
Roger: It seems to me that everything doesn't have to be difficult. Maybe this will be a quick kill.
DaveO: What do you think the ebXML community's opinion would be if a portion of the ebXML stuff was looked at more in a W3C group?
Duane: This was strongly considered.
... The business level agreement explicitly acknowledges this.
... The reason I'm part of your group is that they would like more harmonization and interop.
DaveO: If you look at something like the ebXML messaging service
spec, there's a whole bunch of things in there. Some would fit in well with
WS, and some don't, such as security.
... Is there interest in factoring the ebXML stuff?
... There is a great deal of willingness to work in that context and have requirements from this WG to be fed back into their group.
... A lot of ebXML specs were built on visions of what business people wanted and have maturity in that regard, though the tech aspects weren't as mature.
<Roger> wEB sERVICES
MikeC: WS Desc WG just reported a straw poll preferring "Web Services".
Scribe: Straw Poll:
... Option A: Web service
... Option B: Web Service
<geoffa> I vote for A
<JimD> Dave Hollander also mentioned on email today the option for wEB sERVICES
Results: Option A: 13 Option B: 6.
MikeC: So based on the reasoning that we're responsible for defining terms, we'll go with Option A: "Web services" and take it to the CG.