Wednesday March 1, 2000, 14:00 PST
San Jose Convention Center room J1
San Jose, CA, USA
The BOF was announced on xml-dist-app@w3.org and during the opening keynotes on February 29th and March 1st. The BOF was attended in person by interested XTech attendees and by Ken MacKleod via a phone bridge.
[C. M. Sperberg-McQueen took notes during the BOF and passed them on to me. If anyone wished to contribute to the transcript, please mail me. Following the transcript are some technical and procedural issues I remember being raised during the BOF that are not fully represented in the transcript.]
Eric Prud'hommeaux addressed the audience and stated the purpose of the BOF. Paraphrasing: Transporting protocol data in XML is a problem faced by a lot of developers and designers. Between XML-RPC, SOAP, EBXML, and the temptation to roll one-off protocols, there's growing fragmentation. The purpose of this BOF is to see what parties are interested in what level of coordination. Here is Don Box to give a short scenario presentation aimed at establishing common goals and vocabulary:
Don Box:
Party A wants Party B to do something. A wants to send something to B. More and more people want to send it in XML. Sometimes, the result is a response in the form of XML message. All we see with a packet sniffer is XML.
What is this thing? Is it XML RPC? Is it XML messaging? (Different show of hands.) What's the difference? Three is no difference we want to talk about. At the end of the day, messages and RPCs contain info and send it around. Everyone is coming up with different ways to map their application data into XML. There is no canonical mapping from abstractions we all agree upon into XML. OMG has already standardized a canonical form for representing and defining these things. No one has agreed on that mapping.
I work on SOAP; we don't want to pitch it as a standard -- it's just something we did in a semiopen process. How do we serialize into XML? Principal author of SOAP came up with a canonical form: use sub-elements. If we can get a simple straightforward way to go from programmatic types into XML, some of us won't even have to learn XML Schema. SOAP has a canonical mapping; you may not agree with it but I encourage you to look at it and disagree with it; rip it to shreds. But whatever form it takes, we need to agree on a serialization formats. How many Java serializers in the room? Five. Same format? No. What happened to write once, read anywhere.
Jon Bosak said that W3C exists solely to lay down an infrastructure for us to build upon. It's the job of Oasis to build vertical market applications on it. The charter of W3C is to deal with the common infrastructure.
It's not a big stretch to come up with a canonical mapping from CORBA or something into XML.
Eric: part of the goal here is to find out what people's wish list is. What are the requirements? What is key is that we look at the requirements for the foundation. What are the requirements for a messaging or RPC language that allow us to support people's other requirements? Proposal of four [listed on a flipchart]:
I'd like to use this as a starting point [strawman] to see where this model doen't meet people's needs.
Vaguely moderated discussion ensued. At this point there were forty-one people, standing-room only.
Henrik Frystyk Nielsen: We want a little pocket you can put things in.
Bray: it's important to be self-contained. When you get this, you must not have to go somewhere else to pick things up.
DV: I have heard people asking to build something which is very fast, for transaction processing.
Noah Mendelsohn: I am concerned that we haven't clarified what this is about. My impression is that this is misnamed; what we are discussing is data representation in XML; one use for this is XML messaging, but that's not it. That's not the purpose that we ;.. The difference between request/respone and streaming are big. We have to make sure we're not blowing by the question of what we're doing.
One possible set of goals is: should W3C help the world invent request/response protocols and broadcast protocols? One is data representation?
Eric: our view is that we should be able to take the extension mechanism and build whatever you want. It's likely that within this group ...
Joe Lapp, webMethods. We had a BOF at Netscape not long ago. There are lots of people going in with hammers in their hand and no idea of what building we are trying to build. What standardization need is there?
N.N. when I got involved, I wanted the kind of capability we had had on desktop applications, only running over the Internet. Connecting tools to servers, proxies, etc. (UserLand).
HFN: a lot of people ar ein the position you describe. Our goal should be to describe the commonalities among all of these things people are building. Interoperability.
UL I'm in favor of this happening quickly. Ratify SOAP!
EP: we need to figure out what the requirements are.
N.N. or at a higher level, data model (serialization).
Can we do this fast in W3C? Isn't there a risk that at the end of the day TBL could just say "Oh I don't like it, so go away"
Tim Bray: it used to be easy to be fast in W3C, but now W3C is the center of the universe and nothing can go fast.
HFN: getting consensus takes time.
N.N.
David Orchard: if W3C can't move fast, should we slow it down more by adding IETF?
rpc guy: if Sun and MS would agree, it could happen fast.
Proposal to do it ourselves in an open list, and ask W3C to rubber stamp. Eric: the rubber stamp is not the key. If we design what we need, the rubber stamp doesn't matter.
Don Box: I can't think of any substantive criticism of SOAP that haven't been addressed or on the issues list.
Joe Lapp: we are here to discuss how to get official ratification.
EP: we are here to decide what it is that we want to have ratified.
Tim Bray: We aren't building a building in a green field here. RPC and SOAP have already hit the 80/20 points. Just ratify them as fast as possible?
Noah Mendelsohn: SOAP is a solution. Why should we rubber stamp it? SOAP purports to solve some problem. Somewhere between boiling the ocean and doing nothing there might be a sweet spot. Could we do a bit of work to say what problems this is supposed to solve?
Turner: this is not just about SOAP and XML-RPC. You all saw Benoit's list. Every single one of them has some aspect of this in what they are doing. We are getting too latched onto the original app area of SOAP as opposed tot he fact that all of these things are doing the same thing, in different ways. In the same way we agre on how HTTP works, we need to agree on how this level works.
N.N. There is enough stuff deployed out there already that it's too late. Turner: I'[m not saying stop what you're doing -- nobody wilol. But start a parallel path and come u pwith a common way of doing that common piece. And over time we can converge.
There are common pieces: an envelope. A header\ for routing, etc. YOu can go through each one of these. The large body of existing work should make this easier.
Box: a functional parallel to OMG's CDR. Take programmatic types and serialize them.
HFN we have to agree on having the same extensibility model.
Orchard: what kind of standards body shold deal with the serialization? If we want a serialization of Java objects, should we define it, or Larry Cable? What's the SQL to XML binding? What ISO committee owns that?
EP people could say "Well, this will work itself out, call me when it's over, I'm going home to get some sleep." Or we can be interested in finding a common solution to avoid fragmentation.
EP: regardless of where it goes in the W3C process, if we reach agreement on the open mailing list we will have something.
DV: first step: join the mailing list and discuss.
RPC guy. Growth is the reason we want to ratify SOAP.
Joe Lapp: here's something that gives you instant connectivity, automatic integration with anybody else without defining DTDs, etc. That's one business problem. Second problem: I have an enterprise portal that is going to be chatting with umpteen companies about trades; I need to accommodate individual needs of individual companies.
N.N. There are lots of areas (? errors?) we need to standardize.
Larry Cable, Sun. This is a replay of earlier debate. One camp wants SOAP now. Another camp wants to step back and define the problem. I have to support Noah's comments. There is clearly an interest in doing this, in the open process. If you're not prepared to accept the cost of the open process, go ahead and leave the room and try to sell your solution on the open market. The rest of us who stay must be committed to going through the open process. Write it down, implement it, and get on with it.
DV: please subscribe to the list.
LC: it's the same warm bodies. Do it in one place, not twice in W3C and IETF.
How many people think W3C shjould be involed? 2/3 or so.
How many want to ratify SOAP as is? (no one?)
How does it work? DV explains proposal for activity, WG, requirements, draft, last call, candidate rec, proposed rec, AC review, ...
Bray: come in low and fast, like XML
NM: focus on the data representation part. there are a couple of things already going on. schemas. Schema doesn't say what an array is; we could, though. If you take off the idea that this is about messages, and say this is about data types, it might go into Schemas. Maybe not. Query is also attacking this.
Cable: the consensus is that we do need a W3C effort. We have to address also the existence of the nascent IETF BOF.
EP: sign up.
Box: the plan is to build consensus on the mailing list, as to the next step.
-- end of moderated discussion --
Here is a probably incomplete list of the dissenting or enhancing technical opinions raised during the BOF. [Many of these are from memory and aren't in the transcript - sorry]:
Dave Winer suggested that W3C reccomend XML-RPC as an interim standard while we sort out what we hope to produce here. See the Viewpoints document for details.
Glen Daniels and Noah Mendelson were concearned about making the assumption that the protocol layer is nested above (inside of) the serialization. See the Viewpoints document for details.
Ken and several others expressed concearns about having an option to serialize in a simple, lean format. See the Viewpoints document for details.
One of the objectives of the BOF was to determine who was interested in W3C taking some role in XML protocol development. About midway through the discussion, when we had about 50 people, Eric asked for a show of hands of who was interested in XML protocol consolidation, W3C involvement, and an open W3C process. These bullets came from the ensuing discussion:
Most of the people at the BOF were interested in seeing some work done to avoid XML protocol fragmentation. Not too surprising, they wouldn't have skipped other sessions to attend the BOF otherwise.
At the worst, there were about 25 people in favor of W3C involvement. Other's felt it should be managed at IETF or hammered out amoungst a group of geeks like those present. The criticisms dealt process openness and sluggishness.
Some folks were concearned that the process would not be accessible to non W3C members. Eric said that the process was likely to be open, and that there were precedents for open processes, like digital signatures, which is a working group shared with IETF.
Addressing the perception of W3C processes as sluggish, I stressed that all the alternatives also relied on consensus and that was the most consistently retarding force. Once consensus has been reached, and developers have confidence in what they've arrived at, they can go ahead and role out the products with relatively little fear of the specification changing.
Eric Prud'hommeaux,
@(#) $Id: 02-XTech2000-protocol-BOF.html,v 1.10 2000/03/20 13:22:23 eric Exp $