WS Architecture WG Telcon
5 Jun 2003

See also: IRC log

Attendees

Contents

• Agenda Items
  1. Martin's SOAP UML harvesting
• Summary of Action Items

Scribe: Discussion on f2f venue

<chrisf> nc

<geoff_a> nc

<mitrepauld> prefer NC

<frankmccabe> strong pref for NC

<Roger> Prefer NC

<mmahan> nc

Scribe: Straw poll being taken to see preference for Toronto or North Carolina
... Some objections to Toronto, but no objections to NC

Scribe: ACTION: Heather to send logistics for getting to NC

<Roger> I'm getting quite a bit of static -- possibly from PaulD or Frank.

Scribe: ACTION: Mike to sync up with WSD WG about the f2f being moved to NC

<Daniel> LOL nobody is outside in the daytime Doug...only mad dogs & englismen

<dbooth> ACTION: MikeC to sync with JMarsh about change of F2F to North Carolina

<dbooth> ACTION: dbooth to send email to WSA and WSD admin lists about changing the F2F to North Carolina

<mitrepauld> http://www.xmlconference.org/xmlusa/

Scribe: Discussion on possibility of WS Tech Plenary to be near-concurrent with another event such as XML 2003 Conference

<mitrepauld> hugo, chris: discussion of "workshop"

Scribe: Possibility of joint meetings or workshop for cross-pollination discussions.

Scribe: WG is interested, worth having a look at the idea.

<mitrepauld> Hugo: points out this is 6 months away, and documents will be more stable

<chrisf> is there a link to this conference?

<mitrepauld> mc: wsd aligning wsdl with daml-s and rdf
... ericn: beware basing architecture on specific versions of a technology (SOAP, WSDL)

Hao: Is there a NEED or a MUST for SOAP and WSDL?

<chrisf> hao: large base of usage of XML over HTTP that is not SOAP

<mitrepauld> daveo, Should WSA require a WS to have a well-defined processing model, therefore, WSDL HTTP binding may not make the cut? SOAP 1.2 is okay. Others okay?

FrankM: Can't assume interoperability is possible just because XML is used.

Hugo: See our role as aligning concepts from SOAP and WSDL with WSA.

Daniel: Let's address concepts rather than implementations.

<mitrepauld> daniel: feels strongly that WSA should not be tied to a particular version of specs like SOAP, WSDL.

<hugo> Hugo agrees with Frank and Daniel

<mitrepauld> mc: concepts by reference, versus WSAWG job to extract concepts from those specs

Ugo: Should at least support SOAP & WSDL, though not exclusively.

<mitrepauld> daveo: WSDL description for HTTP GET to return jpg image.

DaveO: Should talk about relationship with SOAP and WSDL.

<mitrepauld> WTDL = Web Thingy Description Language

<DaveO> :-)

<dougb> Agree with Chris' comment which is related to the 'I'm using RMI, where to I do the binding?' question. Do we end up with a differently named (typed) thing if the answer is a SOAP versus WSDL binding?

ChrisF: Bottomline is that we are mapping on top of WSDL and SOAP.

<mitrepauld> cf: Java RMI binding to a web service. Talk about mapping, sometimes good fit, sometimes not. Don't boil ocean. Stick with the core stuff.

<ericn> +q

<DaveO> Chris, so you are asserting that the WSD language can describe more than Web services. And there's no need to define a name for what those other things are, like xml over http.

<chrisf> yes, they are what they are

<mitrepauld> roger: WSDL can describe things that are not WS

<chrisf> now, if there were a model whereby the SOAP infoset was mapped to IIOP for instance, or JRMP, or DCOM (or whatever .NET is based on) then maybe it would make sense to talk about the things that have a common abstract interface and alternate bindings as Web services... but IMO you need them to be based on the SOAP Infoset model as a foundation for the oter WS-Sploat work to make sense in the context of alternate bindings to other than SOAP

<DaveO> here's my big fear: We decide that xml/http isn't part of web services. Then some people can argue that because they aren't part of Web services, WSD doesn't need to describe them.

<Roger> I thought that SOAP required a header -- which is not exactly bare HTTP.

<mitrepauld> ericn: XML is extensible by definition. standards specify minimum essential things.

<dougb> I note that HTTP GET can be supported using WSDL HTTP binding or WSDL SOAP binding with SOAP 1.2 GET feature -- we don't get out of the muck that easily

<Roger> Don't you still need a SOAP header? In other words, it isn't just a GET?

<Hao> agree with DaveO

DaveO: Wants WSDL to continue to be able to describe things like XML/HTTP

<mitrepauld> Does WSAWG need to say that it is okay for WSD to work on describing things beyond the scope of "WS"?

<MChapman> +1 to chris

<ericn> ditto

Chrisf: Should not boil ocean, cannot achieve interoperability if we try a broad scope.

<DaveO> chris, you are not making a fair argument. I have said for the nth flipping time that we clearly focus on how wsdl and soap fit together, and how extensions are created.

<chrisf> note that I also agree with Eric's point that we do want to articulate the architecture in terms of its constraints and not in terms of specific versions of technologies, but that issue is separate from scoping the domain of the architecture

<ericn> agreed

<chrisf> daveo, I don;t understand why you think that this isn't a fair argument?

<DaveO> the whole bicycles being different than cars is silly. It would be more like Daimler inventing the car, but calling it "bicycle zoom zoom" or something like that, and then saying that "bicycles" aren't part of "bicycle zoom zooms".

<dbooth> DougB: I note that HTTP GET can be supported using WSDL HTTP binding or WSDL SOAP binding with SOAP 1.2 GET feature -- we don't get out of the muck that easily

<mmahan> but chris, isn't what you agreed in eric's argument the essense of +5?

<ericn> So the domain of the architecture is outlined by SOAP+WSDL, but needs to be expressed in terms of constraints, properties, and concepts

<Hao> Chris, in many cases, peopel don
... don't need those stuff provided by SOAP

Martin's SOAP UML harvesting

<mitrepauld> mc: Martin's UML diagram discussion.

<chrisf> responding to dougb's point in the irc log above regarding HTTP GET and SOAP1.2 GET WebMethod, agrees that in that particular case, there is indeed a similarity on the wire (e.g. the request is an HTTP GET but in the first case, the response is not necessarily SOAP but in the second case, the response is a SOAP message

<mitrepauld> http://lists.w3.org/Archives/Public/www-archive/2003Jun/att-0009/Soap_Uml.png

<chrisf> but the key point is that in that particular case, what we did was to come up with a formal binding of the SOAP infoset. Of course, it also means that effectively, you are limited to the features (expressed as SOAP modules) that can be used in conjunction with the SOAP GET

Martin: Has sent UML diagram. Wants to build one comprehensive diagram with that of WSD diagram.

<mitrepauld> what is the "path" diamond?

Martin: Path diamond indicates ternary relationship

<hugo> there is only 1 identified (with a URI) ultimate receiver

<mitrepauld> rat hole: only one ultimate receiver vs multicast

<hugo> the message can be processed by whoever taking this role

<dougb> cya

<mitrepauld> receiver is-a role. agent has-a role?

Martin: Will continue working on the UML diagram.

<dbooth> ACTION: MChapman and MMahan to work on UML description of WSDL

Scribe: ACTION: Martin and MikeM to work on UML diagram for WSD and get both diagrams merged.

<MChapman> later guys

<Roger> My information is that WSA is first.
... At the F2F.

<dbooth> Roger, http://www.w3.org/2002/ws/desc/3/05/f2fJulyLogistics.htm
... Roger, yes, WSA is first.

<Roger> DBooth, Right. Which says WSA meets first, not second.

Summary of Action Items