WS-Description Face-to-face

3 Mar 2005

See also: IRC log


Rebecca Bergersen, IONA Technologies
David Booth, W3C
Allen Brookes, Rogue Wave Software
Roberto Chinnici, Sun Microsystems
Glen Daniels, Sonic Software
Paul Downey, British Telecommunications
Youenn Fablet, Canon
Hugo Haas, W3C
Anish Karmarkar, Oracle
Jacek Kopecky, DERI Innsbruck at the Leopold-Franzens-Universitšt Innsbruck, Austria
Amelia Lewis, TIBCO
Jonathan Marsh, Chair/Microsoft
Jeff Mischkinsky, Oracle
Dale Moberg, Cyclone Commerce
David Orchard, BEA Systems
Bijan Parsia, University of Maryland MIND Lab
Tony Rogers, Computer Associates
Asir Vedamuthu, webMethods
Sanjiva Weerawarana, IBM
Umit Yalcinalp, SAP
Jean-Jacques Moreau, Canon
Steve Winkler, SAP
Charlton Barreto, webMethods
Philippe Le Hegaret, W3C
Kevin Canyang Liu, SAP
Jonathan Marsh
GlenD, bijan


New Vote Bot demo

Paul introduces the new Vote bot, and we vote on what name it should be given.

<p> <em>Timestamps are in UTC.</em></p>

<pauld> vote, say hi

<pauld> vote, question: what shall we name our baby?

<Marsh> vote, option 0: vote (status quo)

<Marsh> vote, option 1: Chad

<Marsh> vote, option 2: Kerry

<jeffm> vote option 2: 666

<dmoberg> vote, option 1:Chad

<Marsh> vote, option 3 straw

<Marsh> vote, option 3: straw

<Roberto> vote option 4: Spartacus

<jeffm> voite option 5: 666

<Marsh> vote, option 4: Spartacus

<Marsh> vote, option 5: 666

<Marsh> vote, summarize

<GlenD> vote: 1, 4, 0

<Marsh> vote, options?

<pauld_> vote: 1, 3

<RebeccaB> vote: 0,3

<Marsh> vote: 1, 3

<umit> vote, option 100: umit

<Allen> vote: 1, 3

<alewis> vote: abstain

<Roberto> vote: 4, 3, 5, 0

<TonyR> vote: 3, 1, 4

<charlton> vote, options?

<asir> vote 1, 2

<jeffm> vote: 5, 1, 3

<hugo> vote: 3

<youenn> vote: 4,0

<bijanp> vote, options?

<asir> vote asir 1,2

<swinkler> vote: 1

<pauld_> vote, votes?

<Marsh> vote, option 7: VoteBot

<JacekK> vote: 3, 7, 0

<bijanp> vote: option 4, 5

<GlenD> vote, count

<umit> vote: 4, 100

<vote> Winner is option 1 - Chad

<Marsh> vote: Gudge: 100

<Marsh> vote, count

<vote> Winner is option 1 - Chad

<pauld_> vote, detail

* vote Election: what shall we name our baby?
* vote Method: British Columbia STV
* vote Number of Ballots: 14
* vote Threshold Name: Droop Static Whole
* vote Threshold Value:  8.0
* vote Delayed Transfer of Surplus: Not Enabled.
* vote Batch Elimination: None
* vote 8 candidates running for 1 seats.
* vote  R|   0|   1| 100|   2|   3|   4|   5|   7|Exha|Surp
* vote --+----+----+----+----+----+----+----+----+----+----
* vote  1| 1.0| 5.0| 1.0| 0.0| 3.0| 3.0| 1.0| 0.0| 0.0| 0.0
* vote  3| 1.0| 5.0|    |    | 3.0| 3.0| 1.0|    | 1.0| 0.0
* vote  4|    | 5.0|    |    | 4.0| 3.0| 1.0|    | 1.0| 0.0
* vote  5|    | 6.0|    |    | 4.0| 3.0|    |    | 1.0| 0.0
* vote  6|    | 6.0|    |    | 5.0|    |    |    | 3.0| 0.0
* vote  7|    | 7.0|    |    |    |    |    |    | 7.0| 0.0
* vote Round  1: Count of first place rankings.
* vote Round  2: First elimination round.
* vote           Eliminating candidadates without any votes.
* vote           Eliminating candidate 2.
* vote           Eliminating candidate 7.
* vote Round  3: Tie when choosing candidate to eliminate.
* vote           Tie at round 2 between 0, 100, 5.
* vote           Tie at round 1 between 0, 100, 5.
* vote           Tie broken randomly.
* vote           Eliminating candidate 100.
* vote Round  4: Tie when choosing candidate to eliminate.
* vote           Tie at round 3 between 0, 5.
* vote           Tie at round 2 between 0, 5.
* vote           Tie at round 1 between 0, 5.
* vote           Tie broken randomly.
* vote           Eliminating candidate 0.
* vote Round  5: Eliminating candidate 5.
* vote Round  6: Eliminating candidate 4.
* vote Round  7: Eliminating candidate 3.
* vote           Election over.  Candidate 1 is elected.
* vote Winner is 1.

<GlenD> Scribe: GlenD

<scribe> Agenda: http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/0071.html

Discussion and demo of Paul's new votebot

<pauld_> vote, i'm going to rename you chad :-)

Assign scribes

3/3 AM : Glen

3/3 PM : Bijan

3/4 AM : Roberto

3/4 PM : Allen

Agenda Bashing

Swapping morning and afternoon in agenda for Friday - start at 8AM

Alternate schema languages (LC70)

Jonathan summarizes - move alternate schema language bindings to appendix, Bijan volunteered to coordinate

Jonathan: What else remains of issue 70?

Bijan: Data Access group now has a dependency on WSDL 2.0
... Hard to use schema to validate RDFXML, so nice to use RelaxNG for that...
... So in a single WSDL you might want both

Asir: There was a proposal from DBooth about mixing languages

<asir> David Booth's proposal - " include a note in the spec saying that if someone combines multiple schema languages may be a problem, and we have not solved this problem".

Sanjiva: What are the problems here?

Amy: Basically, it's that behaviour is undefined

Amy describes scenario where both RelaxNG and Schema are used

RelaxNG proposal reuses the element="" attribute

scribe: so there can be a QName conflict

Jonathan: Question - do we want to allow different defs in the same file?
... Question - do we want to allow referring to different defs with the same attribute?

Bijan: One operation, input has single XML schema type. output can be one of two types (schema, relax). Could do two ops, but nicer if it's one...

various: are they the same?

Jacek: If not, they are like a <choice> with the choices being in different schema langs
... Do we want to allow one QName defined by both schema/relax and have it be the same?
... Should RelaxNG contribute to the element declarations component? I'm doubtful, but if so it shouldn't contribute a different component....

Jacek: We could also say RelaxNG defs are not element declarations (different component)
... Could say that there is EXACTLY ONE component on a message ref which defines the schema (small s)

Roberto: Two probs. Sec 2.1.3 (element decls) says it's a set - we require all elements to be isomorphic to a schema element decl... could require the QName for each element decl to be unique in the set (preventing alternates)
... 2nd prob - message reference (2.5.3) says "the" element declaration, already implicitly says that there will be exactly one.

<sanjiva> +1 for Roberto's approach for saying the set of GEDs in {element declarations} consists of unique QNames

<JacekK> we already say what Roberto wants to say in 2.1.2 penultimate para

Sanjiva: We decided not to have "type" on the output, so if you want choices, you use the choices facility of the schema language
... If we disallow other schema langs to contribute to the element decls, we disallow the use of our binding
... since the binding refers to that component

<umit> +1 to Roberto's approach

Tony: Multiple schemas seem to be about using multiples to allow people who understand various langs to understand a given WSDL (you can use one and ignore one, say)
... That leads to picking exactly one, not alternates

Glen: I saw it rather like Tony - alternates (which describe the same infoset) seem like a good possibility

Jonathan: Can we focus on that question (should we allow alternates)?

Roberto: Worried about interop / sychronization problems

Amy, etc : Not our problem

Jonathan: DavidB suggested that alternate descriptions should be representations of the same thing - if they're different, your problem

Sanjiva: When processor is building stuff, it looks at the QName and picks whichever descriptino of that QName it likes

Asir: Let's dedicate element="" attribute to just schema, and use something like rng:element="" for RelaxNG, etc

Sanjiva: That doesn't solve the problem...

Jacek: 2.1.1 already solves Roberto's problem
... already can't have two components with same QName
... Let's allow multiples, which are strongly suggested (but not enforced) to describe the same thing

<Zakim> JacekK, you wanted to point roberto is trying to add that constraint in the wrong place

Jacek: Multiple schema versions would generate a single element decl component

Sanjiva: So you pick one for schemas, but not for other langs?

Jacek: Logically it's a merge (for versions of schema), but ok to think of it as pick one...

Sanjiva: element decls component designed for extensibility of XML Schema versions
... In order to deal with RelaxNG, etc. - it should be OK for the processor to choose how it builds that component
... Our component says the four things we need (localname, namespace name, etc) - you can populate that any way you like

<JacekK> editorially, we are inconsistent in saying "element declaration" and "element declaration component"

Sanjiva: But you should only do it once (pick one of multiple descriptions that should all be the same infoset)

Asir: So this is implementation dependent?

<asir> "This specification allows mixing schema languages within WSDL and such usage is implementation-dependent".

<umit> +1 to Sanjiva

Glen: Don't like the wording here (too loose, implies "mixing" languages together?).. idea is good

Tony: Do not want to enforce sameness requirement - we can't.

<Zakim> JacekK, you wanted to ask about how it fits with OWL classes

Jonathan: i.e. does an OWL class define local name, namespace name, etc....

Jacek: OWL doesn't define that

Sanjiva: Then it doesn't apply

Jacek: Messages are XML elements... the story about OWL could be that OWL has to create glue from an OWL class to an element declaration.
... If there is a really funky type system, then they can use new components (not element decl)

<pauld> sorry, i care deeply about OWL ..

Sanjiva raises issues about complexity of alternate componentry, Glen notes that we don't necessarily need to go there (OWL binding to WSDL can create element decls)

Bijan: Asir's text - does mixing schema languages imply implementation dependent or extension dependent?

Jonathan: Implementation chooses... using standard WSDL requiredness criteria

Bijan: Not so hard to prove equivalence between some schema langs

Sanjiva: Could define any kind of extension (java, indigo, etc) which tells how a "thingy" turns into a GED
... That would work for OWL classes as well

<pauld> <a href="http://www.flickr.com/photos/psd/5812127/">http://www.flickr.com/photos/psd/5812127/</a>

Roberto: MustUnderstand on a relaxng extension would seem like you need to validate both?
... i.e. if a schema (implicit MU) and RelaxNG (required=true) are both present, then the infoset must validate both

Jonathan: 1) Element decls are unique per QName, up to impl to pick one if multiple
... 2) They're not unique, and everything that's required MUST go into that list, other stuff MAY

<Zakim> GlenD, you wanted to ask about validation and the element declaration component

Tony: OK for different schema langs to have different constraints, as long as they're subsets - should be OK

<TonyR> Perhaps: as long as they have the same XML representation...

<sanjiva> Given the complexity this conversation is heading towards, I would prefer to get married to XML Schema and only XML Schema and live with it. Sigh.

(discussion of wsdl:required and the semantics thereof)


break for coffee


straw polling options

<pauld> chad, hi!

<pauld> chad, you're owner hasn't written that page yet :-(

<pauld> chad, proxy all TonyR's votes to me!

Jonathan describes the usage of two versions of schema to allow for versioning and backwards-compatibility

Amy: 2nd use case is about wsdl:required being used to indicate that you have to understand relax to deal with message ref components which are only defined in terms of relax

straw poll (this time for sure)

<pauld> chad, hi

chad, you're not pauld

fine chad, stick with your illusions of grandeur

<pauld> chad, i'm pauld

<sanjiva> chad, who are you? cousin of votebot?

<pauld> chad, die die die

So we're going to clean this up to be consistent, but the poll is about whether or not a given QName has exactly one description, or potentially multiple ones

unique: 6

non-unique: 5

abstain : rest

can't live with unique : 0

can't live with multiple : 2

consensus is to make it unique

<scribe> ACTION: editors to clarify in sec 2.1.3 and elsewhere that there be only a single element declaration in the set for each QName

Jonathan: do we need to clarify if/how a processor chooses which one?

<Roberto> need to make corresponding edits to sections 2.3.3 and 2.5.3 too

Sanjiva: let's just say it's not defined behavior

<Roberto> how is that interoperable? "no defined behavior"??

<charlton> "include a note in the spec saying that if someone combines multiple schema languages it may be a problem, and we have not solved this problem"

<charlton> (David Booth's proposal)

<scribe> ACTION: editors to add text along the lines suggested by David - "include a note in the spec saying that if someone combines multiple schema languages may be a problem, and we have not solved this problem"

Discussion of type system extensibility and CR - should we make sure someone wants to use it in order to get out of CR?

<scribe> ACTION: Jonathan to formalize the CR criteria bag and drop "testing type system extensibility" into it

Jonathan: Do we want people to really review this thing? Do we just publish it or do we do a Last Call or somesuch?

Bijan: need to think about it

<scribe> ACTION: Jonathan will ask the WG what is the publication plan for the type system note around 3/17

[Issue left open temporarily, to see if Issue LC5f resolution applies.]

Issue LC5F, QA review

<Marsh> <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/0099.html">http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/0099.html</a>

upcoming straw poll re: how to deal with schema / import / extensibility

<pauld> chad, option 1: schema is like any other extension

<pauld> chad, option 2: implicit wsdl:required on schema

<pauld> chad, option 3: barf

<pauld> chad, question: are we going to eat lunch on time?

<pauld> vote: alewis: 2, 1

<pauld> chad: alewis: 2, 1

<anish> chad: 1

<umit> chad: 2

<pauld> chad, say hi

<Roberto> vote: 2, 1

<dmoberg> chad: 2, 1

<JacekK> chad: 2

<Roberto> chad: 2, 1

<Allen> chad: 2

<pauld> chad, options?

<RebeccaB> chad: 1,2

<alewis> chad, option 3: provide elements in wsdl namespace corresponding to xs:schema/import

<alewis> chad, options?

<youenn> chad: 1

<bijan> chad: abstain

<hugo> vote: 1, 2

<sanjiva> chad: 2

<jeffm> chad: 2,1

<hugo> chad: 1, 2

<asir> chad asir 1,2

<Marsh> chad: 1, 2

<jjm> chad: 1

<pauld> chad: 1,2

<JacekK> chad: 2, 1

<sanjiva> chad: 3

<pauld> chad, voters?

<TonyR> chad: 2,1, 3

<pauld> chad, voters?

<dbooth> chad: dbooth abstains

chad: 1

<pauld> chad, count

<chad> Winner is option 2 - implicit wsdl:required on schema

<pauld> chad, count

<asir> chad, detail

<chad> Winner is option 2 - implicit wsdl:required on schema

<sanjiva> chad: 2

<asir> chad: 1

(discussion about defining the options)

Sanjiva: Option 1 seems to beg for profiling...

Jonathan: But why force support of Schema 1.0 forever??

<TonyR> chad: 1, 2

Sanjiva: Same can be said re: XML 1.0 for SOAP

<JacekK> chad: 1, 2

<alewis> chad: 1, 2

<alewis> chad: count?

<TonyR> chad, count

<chad> Winner is option 1 - schema is like any other extension

<alewis> chad: detail?

<pauld> chad, detail

<anish> option 4 (d): make it a requirement that whenever xs:schema is used, wsdl:required='true' MUST be specified

<umit> option 4 is still not making understanding schema required

<asir> chad asir 1

<pauld> chad: 1

<Roberto> chad: 2

chad, what is the question?

chad, options?

* chad question: are we going to eat lunch on time?
* chad     option 1: schema is like any other extension
* chad     option 2: implicit wsdl:required on schema
* chad     option 3: provide elements in wsdl namespace corresponding to xs:schema/import

<pauld> chad, votes?

<dbooth> chad, option 4: Require wsdl:required=true be written on every xs:schema and xs:import element

<RebeccaB> chad: 1

<dbooth> chad: 1

<jeffm> chad: 1

<dbooth> chad: 1, 2

<sanjiva> chad: 3, 2

<anish> chad: 4, 1, 2

<hugo> chad: hugo abstains

<umit> chad: 2,4

<alewis> chad, count?

<chad> Winner is option 1 - schema is like any other extension

<asir> chad: 1`

<asir> chad: 1

<dbooth> chad, details?

* chad Election: are we going to eat lunch on time?
* chad Method: British Columbia STV
* chad Number of Ballots: 18
* chad Threshold Name: Droop Static Whole
* chad Threshold Value: 10.0
* GlenD ding ding ding - lunchtime
* chad Delayed Transfer of Surplus: Not Enabled.
* chad Batch Elimination: None
* chad 4 candidates running for 1 seats.
* chad  R|   1|   2|   3|   4|Exha|Surp
* chad --+----+----+----+----+----+----
* chad  1|12.0| 4.0| 1.0| 1.0| 0.0| 2.0
* chad Round  1: Count of first place rankings.
* chad           Candidate 1 is elected.
* chad Winner is 1.

break for lunch - we will come back and take a formal vote on whether schema should be required (regardless of text)

sorry, vote is option 1 or option 2

<Marsh> chad, hi

<bijan> Meeting: WS-Description Face-to-face

<bijan> Chair: Jonathan Marsh

<bijan> Scribe: bijan

<scribe> Agenda: <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/0071.html">http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/0071.html</a>

Lots of scary talk about good standing

<pauld> s/.. flying to this meeting ...//

Vote on proposal resolving 5F

Options A and B

<pauld> chad, please leave us

Marsh: Glen has an amendment which I shall propose: Interop is important so you should support XML Schema (without a version number, so that as schema moves forward, so does the recommendation)

Roberto: Does this mean we remove the normative status of XML schema?

Glen: No

hugo, if there objectors, how does this amendment affect you? Does it make you change? If it won't change you, I have another idea that might help

glen: that's umit and sanjiva. So how do you feel about that? "If you use WSDL, we strongly recommend usign W3C XML Schema for interop"

Umit: I'm not conviced yet. Let's hear Hugo.

Hugo: Define WSDL2.0 without a required Schema, plus a profile (in a separate document) which sez: USE SCHEMA WITH WSDL 2.0

<dbooth> (Paraphrasing Hugo:) separate out the specification of the WSDL 2.0 language from specifying a conformance profile

Marsh: That could be a conformance clause in our current document

anish: even if you say that you should|must use schema in WSDL, it's still the case that a wsdl processor could ignore it

hugo, So conformance is defined against both WSDL and the 2005 profile

hugo: so we can't ignore the profile

anish: so define clearly what conformance to the profile means

Roberto: so the profile reintroduces the wsdl processor

hugo: perhaps, not sure

umit: yes

sanjiva: who is you

glen: any processor

Marsh: Conformance to WSDL and XML Schema

anish: that's not enough

pauld: who believes that we need to take care of this? the market will sort it out

anish: there's a confusion between requiring schema in *every* wsdl, and *if* the wsdl has schema stuff, you should obey that

bijan: doesn't this just add another level of indirect?

Marsh: it might make the document conformance cleaner

dbooth: yes, I believe that

Marsh: two issues [but scribe lost them]

sanjiva: there seems to be consensus that a wsdl processor should support schema. The question is 1.0, 1.1 etc.

Marsh (as MS rep): there are situations when you don't want schema (e.g., cell phones). Danger of profile

sanjiva: Yes, but we want to encourage schema for interop

dbooth: that's what you are doing

sanjiva: we are mandating in the language

dbooth: this gives allows us other profiles

TonyR: and you can rev profiles independantly of reving the language

Marsh: Statement or profile?

Sanjiva: no seperate document

Glen: introduces another (unnecessary) identifier

Marsh: "strongly recommended"

umit: why do we have a wonderful test suite? What are we testing? How are we doing conformance?

TonyR: you can test conformance to the profile

[lots of chatter]

[about test cases]

Roberto: I don't undertand the reference to cell phones. If we take out processor conformance, we only have document conformances. If someone creates a cell phone profile that sez: "No schema". That's a subset of all wsdls. They'll never see a schema, so how does this change anything?

GlenD: But this is an interop encouragement. if you want maximal interopt between different domains [Marsh's words] Use schema

Roberto: [some sort of disagreement]

GlenD: It's better to build up than to chop out

Roberto, anish, umit: there is no chopping

GlenD: wsdl:required enforced a processing model. If you put one inthere, *someone* needs to understand it.

dbooth: not exactly. If you put in a binding, do you have to understand it? No, because some processors might not care about bindings

Marsh: Stop. Option A won, but there were objections
... Let's consider a statement along the lines of glen's. Does it help?

sanjiva: I remove my objection

umit: I withdraw too with the caveat that we add glenesqitude.

Marsh: We have consensus to select option A augmented with a statement that is glenesque

sanjiva: a clarification point of glen about required? and understanding

[some chatter betweeen glen, sanjiva, dbooth, and umit about the non-normative note that may mention processing]

GlenD: Point 7, friendly amendment, [which he'll type in]

<GlenD> Thus, the meaning of the element cannot be determined without understanding the attached extension.

Marsh: any objections

dbooth: saying cannot is not correct

GlenD: cannot is definitely correct

dbooth: cannot means that it's not possible to understand

marsh: can everyone live with glen's formulation as entered above?

group: YES

GlenD: question about section 8.1 in core. need clarification of sentence fragment from dbooth's action

<asir> I see xml 1.1 in section 8.1 :-(

GlenD: What 8.1 needs to say: [he'll type it cause he talks really too fast for this scribe]

[lots of chatter about wordsmithing 8.1]

Marsh: glen is this editorial?

GlenD: yes it is
... Some stuff about why it's obvious

marsh starts expressing qualms

GlenD reassures marsh


Marsh: can I declare this editorial?


Marsh: any other objections or question about 5f
... Can I close it?

GlenD: I have some concerns about implementation

RESOLUTION: Issue LC5f will be closed with option A plus amendment plus editorial

<dbooth> Resolution to LC5f (accepting option A): <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/0099.html">http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/0099.html</a>

RESOLUTION: Issues LC75r, LC75v, LC70 will be closed as a consequence of lc5f

Open: that LC63 and LC52b will also be resolved by the resolution of LC5f

Considering LC63

RESOLVED Close LC63 with the resolution of LC5F

Discussion of 52b

jacek raises the OWL Class issue again

JacekK: can we postpone while I think

Marsh: Postponed.

<scribe> ACTION: JacekK to figure out what he thinks on this

RESOVLED: LC52b is closed by discussion with raiser and some clarification

<sanjiva> ACTION: part1 editors to check the consistency of statements related to {message content model} in the message ref component definition and the mapping table.

[some chatter about the Z notation, and how to generate it for public]

<JacekK> resolution to LC52b: {message content model} is optional, missing when a different type system is in use

sanjiva: what is the noramtive document, with or without Z?

Marsh: with, even if hidden

[talk about the makefile and arthur using Ant]

Issue 76d: First class support for headers

Marsh: This issues is in a confused state, so the best we can hope for is action items etc.

sanjiva: can we not push it back and just take a formal vote and move on?

Marsh: Do we have a coherent set of options

GlenD: No.

sanjiva: yes we do, the status quo or the incoherent option

GlenD: but daveo has investment etc.

sanjiva: but how much must we accomodate those who aren't here?

asir: I have to do xml schema stuff tomorrow so I don't want it moved then

marsh: let's get it clear now

asir: Proposal, let's look at all the issues, consider, pick one, then tweak it, then vote on it
... second path: come up with a decision tree

Marsh: which do you prefer?

asir: easier to pick one proposal and tinker
... 5 options (including status quo)

Marsh: we'll discuss each of these options

<pauld> chad, how you doing?

bijan: can we make this easier?

sanjiva: amendment: let's break it in headers in abstract and then in the soap (separately)

asir: there are several dimensions. I can present that and then show how proposal relate to that
... Dimension 1: First class mechanism to describe headers

Scribe will now just transcribe what Marsh is writing on the pad

Mechanism to describe headers


How to hook header into WSDL

1st class: interface

2nd class: binding

3rd class: Features and properties or extension

Support at SOAP binding/HTTP binding


<alewis> chad, help?


DO | type | 1+3 | S/H

A | element | 1 | S/H

B | type | 1 | S/H?

C | type | 2 | S/H?

SQ | type | 1-3 | S/H

S=Support for SOAP binding

H=Support for HTTP binding

H?=No current HTTP support but easy extension

DO=DaveO's proposal

SQ=Status quo

The proposal differentiate over the issues described at the below uri

<Marsh> <a href="http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC76d">http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC76d</a>

[discussion between glen and asir that scribe at least cannot follow]

<pauld> chad, poll?

<pauld> chad, question?

Does the Status Quo deal with all the issues of lc76d

<pauld> chad, die die die

Thus far, GlenD and asir have been vindicating status quo

6th subpoint turns out to have been based on a misunderstanding

[acclaim by glen, asir, umit, sanjiva, and others]

sanjiva: IBM's position is that we don't want abstract headers to creep back in
... proposal: go from status quo to proposal C

asir: our position is we'd like to move to something simple *and* independent of F&P

GlenD: why independent of F&P?

asir: we think that headers are first class so we shouldn't use an extension framework

sanjiva: so, ok with C?

asir: yes, I can live with C

GlenD: DaveO wants it at the abstract level

Marsh: some intersection between several proposal and not between others
... let's examine C to see if it can win

<dorchard> Definitely at the abstract level.

<dorchard> I'm in the TAG/XML Schema joint meeting on extensibility/versioning.

<dorchard> Any chance of deferring this for a bit of time?

hugo, I'm unhappy with a Soap only solution

asir, the details are worked out for SOAP but it could be worked out for other protocols

hugo, let me get some clarification. Will we remove the application data (AD) feature?

hugo, are we replacing an abstract feature with soemthing soap specific

sanjiva: I don't actually endorse proposal C, but something similar to proposal C with devils in the details

backchat between sanjiva and asir about reconciling their Cs (replacing type with element)

GlenD: Task force can present in the half hour before the break

dorchard, we can defer until after the break. will you be able to make it?

<dorchard> yes.

Asynch task force report

<dorchard> if the break ends not before 3:30 :-)

Break is scheduled for 15:20

over at 15:20

<Marsh> <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2005Mar/0000.html">http://lists.w3.org/Archives/Public/www-ws-desc/2005Mar/0000.html</a>

GlenD: Task force formed in Austraila
... Trying to solve longtime issues. Lots of use cases
... Lots of questions about how to decribe important stuff in wsdl
... and the relations between SOAP, WSDL, and WS-Addressing
... Consider the soap layer: impoverished set of MEPs. So how to map from WSDL one way to SOAP?
... options: beef up soap meps with a true oneway. simulate one way with soap twoway.
... what do we want to have happen, and who does it? SOap group? WSDL Group? A merry band of wanderers?
... Big question: If you have a SOAP binding (like ours), can you *extend it* without changing the URI?
... MTOM not an example of doing this, since SOAP allows extensibilty for media type. SOAP does not say this about MEPs
... So, what to do with a new soap MEP?
... Since you *really* have to understand the MEP, it might be ok
... MarkH, can we satisfy these use cases with what he have now? How painful is it?
... Some HTTP magic with redirects
... A kind of asynch, but is it a good idea?
... Do we need to rev soap's level? or can we do it by errata, e.g., add a sentence about mep extensibility
... up to the wsdl level. Do we want to be able to say I've got a WSDL mep and I want to bind it to a different (maybe more than one) SOAP MEP
... or do we want a tighter coupling between the WSDL level and the SOAP/Binding level
... But we don't want to discuss this now.

sanjiva: is this against our last call?

GlenD: yes..well...do we have any issue?

Marsh: yes, 101, 102...

GlenD: Do we need to make any serious changes to WSDL to support these use cases?

sanjiva: we enable everything! by extensibilty!

GlenD: yes, but we want to encourage interop for known topics like addressing etc.

umit: the async task force vote wasn't against *enabling* it, but against *doing* it

GlenD: questions about how hard it'd be even with extensibility
... Moving along. Transport as well as mep variability
... WSLD support for range of options for transport (e.g., for replies) and similar

sanjiva: are we being asked to deal with these for WSDL 1.1

GlenD: The WSDL working group is not being asked to do this for 1.1

sanjiva: Charter says, "don't touch 1.1"

hugo, maybe should we consider it

Marsh: it's part of the web services activity, so we could have our charter revised or interpreted to deal with that

sanjiva, but it's clearly out of our charter!

Marsh: but there's a larger discussion here.

GlenD: It might happen in WS-Addressing

hugo, sorry, I thought you were asking the larger question about dealing with the Addressing questions for WSDL 2.0, not the specific should we help them deal with 1.1

hugo, concentrate on 2.0, and the charter supports that

GlenD: can we drop this, since I don't think we'll do it
... this report is not about making recommendations, but raising the issues in a clear way
... Now that the WSDL group is informed, the wsdl group can punt as they see fit

Marsh: can we relate these to issues 101 and 102 since they relate
... "Subject: Summary of decision tree for Addr/Desc groups

The following is a series of questions which should be considered a tool

for the WS-Description and WS-Addressing groups to use in considering

the plans/actions necessary in order to support various "asynchronous"

use cases as discussed by the async task force. The use-cases we've

been discussing can be found on the archives of the task force list [1].

These questions are divided into SOAP-related, WSDL-related, and

Addressing-related "buckets".

* The SOAP layer

Q. It seems a new SOAP MEP (one-way) is very likely needed. Alternately

it *might* be possible to simply alter the request-response MEP in order

to support the possibility of a "null" response envelope. Does this

work need to happen?

Q. Who should do this work?

a. XMLP group

b. WSDL group

c. Addr group

Q. Regardless of its technical feasibility, it's pretty clear that no

one yet implements a "polling" style callback using HTTP as described by

Marc in [2]. Do we want to try to encourage this pattern? If so:

Q. Where should the work be done to describe it?

a. Errata to SOAP spec

b. Separate note

Q. how do we indicate in the WSDL that this is available/used?

Q. Does this change the SOAP MEP, or is it still a SOAP req/resp?

Q. Assuming both of the above affect the SOAP 1.2 spec(s), can the

changes be published as "errata" so as not to cause a full release cycle

of the spec(s)?

* The WSDL layer

The essential question at the WSDL layer is "what, if anything, do we

need to change in WSDL (both 2.0 and 1.1) to enable the important

use-cases that fall under the general heading of 'async'". This breaks

down into two categories - actual changes to WSDL core, and extensions.

Clearly WSDL core changes (for 2.0 at least) need to happen under the

auspices of the WSDL group. Extensions could be built either by the

WSDL group or the Addressing group (and "who does the work" is therefore

an implicit secondary question to each of the ones in this section).

So here are some questions (these do not necessarily presuppose


Q. Do we want to enable/support the case where a single WSDL

operation/MEP (request/response, say) can bind to multiple SOAP MEPs?

(i.e. the seemingly-common use case where the request comes in on one

HTTP interaction with a <replyTo>, and the response goes out in another

transport interaction (either HTTP or otherwise))

Q. Do we want to enable/support the above with multiple transports?

(req is HTTP, resp is SMTP)" == Issue 101

Marsh: Q. Do we want to enable/support the above with multiple transports? (req is HTTP, resp is SMTP)" == Issue 101

sanjijva: issue 102 is the in-only thing

umit: 102 is the SOAP doesn't give us what we need

(scribe didn't mean to paste all that stuff from glen's message, above)

alewis: we could resolve this simply with a construct/extention that can appear in binding or binding operations or endpoints which says "I support dynamic addressing, and here is the list of uris taht I understand"
... "Send me something back that contains one of these addresses"
... Similarly for the out-only [scribe got a bit lost]
... it doesn't have to be more complicate it enough

sanjiva: make it simpler, just put in a tag (or have Addressing do it)

alewis: be nice to have a list of bindings.

Marsh: If you are interested, join the Task force which meets on Weds

GlenD: TF has determined that it should continue meeting and act as a coordination group for WSDL, XMLP, and WS-A

alewis (correction): for out-initial meps, the wsdl contains a list of protocol bindings (like for in-initial), and the service promises to supply endpoints for each in the outgoing message

jeffm: a lot of discussion revolves around what you expect to see for an in-out
... what should the wsdl do?


Dancing by the harbor

Break is Over

<pauld> chad, i know i've been poking around with your insides, but please do your best :-)

<TonyR> chad, what is blue?

Marsh: asir and sanjiva have had some break time discussion about the proposal C space
... and it seems promising

hugo: (of asir) Why would you want to set up a mechanism to send headers just for a particular binding. That would mean that is is just one particular binding of your abstract applicaiotn that require headers

GlenD: What's this headers thing?

hugo: I thought that was the proposal, to add headers support to the binding

<Roberto> chad, please help

GlenD: The AD feature lets you express abstract things like "Please do security" which, in soap, will poke some headers
... so the abstract claim is, "I want this functionality" i.e, "I have some side band information to communicate too"

Hugo: still uncomfortable with that

asir: hugo, you want the abstract thing?

hugo, I like the AD feature

pauld: Lots of BTers are using headers, usually for good reasoning.
... headers for vendors or middleware! I warn people against mucking with them but they still do it.
... so providing a good header mechanism is a strong requirement for so many people
... we are trying to force people into good practices rather than enabling them to describe what they do and want to do

[some discussion; background filling in for dorchard]

GlenD: there are certainly cases where people are really doing the header thing. But there are lots of other times which look like the first case, but really doing and wanting to do something else

pauld: Ok, that's how you see the world. But it's not clear people want to not do it the headers way

<GlenD> Glen: There are people who are describing headers today in terms of "send this element". There are also cases where they are doing that when they mean "do this functionality".

<GlenD> ...the latter being more in the realm of modules/policy/f&p

Marsh: where we started was can we add simpler syntax for the AD feature

umit: observation that will irritate sanjiva -- In all the proposals, we make diffrent buckets of headers etc. but there is no additional help at the description level/interface level. If the header go wrong and I want to describe what happens I have to muck at the abstract level! So a "binding only" thingy can require abstract mucking

[chat between glen and umit involving holes, AD feature, etc.]

sanjiva: A policy/reliable messaging case

umit: I'm not talking about this. AD feature does not go far enough

hugo: pauld, what do you prefer of the proposals?
... and what the rest of the group thinks. I would like an informative poll

<pauld> i worry about vendor adoption of the AD feature

<alewis> chad, new vote

<chad> new poll

<alewis> chad, question: which of the choices do people prefer?

SQ == Status quo

A == <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/att-0019/first-c">http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/att-0019/first-c</a>


<alewis> chad, option A: first-class headers using elements, binding to SOAP and HTTP

<charlton> essentially inline messages, right?

A==<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/att-0019/first-class-headers-A.html">http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/att-0019/first-class-headers-A.html</a>

<sanjiva> yes basically inlined messages

B==<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/att-0019/first-class-headers-B.html">http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/att-0019/first-class-headers-B.html</a>

<alewis> chad, option B: first-class headers using types, binding to SOAP and HTTP

<alewis> chad, option C: headers defined at the binding level, using types, initially only for SOAP (but HTTP possible)

C==<a href="http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/att-0094/soap-header-blocks.html">http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/att-0094/soap-header-blocks.html</a>

<hugo> chad, list options

D == <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/0040.html">http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/0040.html</a>

<alewis> chad, option D: AD feature with syntactic sugar for direct usage.

<alewis> chad, option S: status quo, the existing AD Feature

asir: AD feature is optional!

<alewis> chad, options?

<alewis> chad, list options?

pauld: which ones do asir and dorchard prefer

<alewis> chad, remove option s

asir: I want a slim option that will get acceptance

pauld: waht if you were the only one voting?

asir: C + extended to HTTP

<alewis> chad, list options?

dorchard: don't like C, prefer either B or D (DO)

<youenn> <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/0046.html">http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/0046.html</a>

RebeccaB: Is this entirely related to SOAP and HTTP or also apply to other transports

pauld: it can apply to other transports

RebeccaB: which proposals apply to the wider range of transport

pauld: could do it in your binding

RebeccaB: so you prefer one of the binding levels?

[discussing of C vs. B (I think)]

umit: Why move from SO? Jeff Schlimmer wants something [scribe misses]. And if we don't satify him, he'll come back.

Marsh: I've not talked with jeff about it, but i may not be

pauld: i haven't talked with him, but i can imagine his comment was able backwards compatibility for expressing this stuff, at least being *able* to express the same stuff in both

asir: in my editing of the soap binding, for the migration of headers users in 1.1, C will help, but A and B will work, but optional features don't help

<JacekK> chad: S, D, A, B

<umit> it seems to me that issue 76 d issues seems to request SOAP 1.1 compatible solution. I wonder whether A, B, or D will help closing the issue. Just an observation reading the actual issue statement

<asir> chad: C, B, A

<sanjiva> chad: C, S

<Roberto> chad, list options

<alewis> chad: S

<Roberto> chad: C, S

<umit> chad: C, S

[youenn explains his solution: <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/0046.html">http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/0046.html</a> ]

anish: Why did we get rid of message structure?

youenn: I don't know. We so agreed. Two ways, inline it (complicated) or create element=qname since it worked 90% case

asir: This covers stuff beyond 76b?

youenn: why?

asir: because it changes soap binding?

youenn: it's a module

GlenD: right, it doesn't change anything unless you use the module.

Marsh: Seems a little obscure. You wouldn't notice it if you were looking headers.

pauld: how would you map 1.1 headers to this?

<anish> it seems to me that we would have been better off by keeping the message structure and allowing minOccurs, maxOccurs and xsi:nil in WSDL

GlenD: you just take the parts and pop them into an element and then route

<RebeccaB> chad: C,S

<hugo> chad, list options

<pauld> chad, list voters

<dorchard> chad: B, D

<hugo> vote: B, D, S, A, C

<TonyR> chad: abstain

[discussion about how you serialize into HTTP]

<hugo> chad: B, D, S, A, C

<Allen> chad, B, D, S

<alewis> chad, option Y: youenn's proposal

<pauld> chad: B, D

<Allen> chad: B, D, S

<dmoberg> chad c, s

<alewis> chad, list options

<dorchard> chad: B,D,A

<pauld> chad: dmoberg: C, S

<alewis> chad, list voters

dorchard: I'm against C because things like BPEL work at the interface level and won't be able to access things at the binding level

<Marsh> option Y: youenn's proposal to have a single wrapper element at the abstract level, containing headers and body, bind it using a module into SOAP body/headers. Without the module, the whole wrapper element get's bound.

<Marsh> chad, option Y: youenn's proposal to have a single wrapper element at the abstract level, containing headers and body, bind it using a module into SOAP body/headers. Without the module, the whole wrapper element get's bound.

<GlenD> chad: S, D

<alewis> chad, list options

* chad question: which of the choices do people prefer?
* chad     option A: first-class headers using elements, binding to SOAP and HTTP
* chad     option B: first-class headers using types, binding to SOAP and HTTP
* chad     option C: headers defined at the binding level, using types, initially only for SOAP (but HTTP possible)
* chad     option D: AD feature with syntactic sugar for direct usage.
 asir: do they want to do stuff with headers?
* chad     option S: status quo, the existing AD Feature
* chad     option Y: youenn's proposal to have a single wrapper element at the abstract level, containing headers and body, bind it using a module into SOAP body/headers.  Without the module, the whole wrapper element get's bound.

asir: do they want to do stuff with headers?

<JacekK> chad: S, D, A, B, C

dorchard: yes, probably.

[some chat between dorchard, sanjiva, asir about BPEL]

<Marsh> chad: B, C

<youenn> chad: Y, S, D

<anish> chad: S, D, C, A, B

<jjm> chad: Y, C, A, B

<jeffm> chad: S,D,C,A,B

<anish> chad, list voters

chad: B, S, B, C,

<alewis> chad, list voters

chad: B, S, B, Y, C

<GlenD> chad: s, s, s, s

chad: B, S, A, Y, C

<GlenD> chad: s, d

<alewis> chad, count?

<chad> Winner is option C - headers defined at the binding level, using types, initially only for SOAP (but HTTP possible)

<alewis> chad, details?

* chad Election: which of the choices do people prefer?
* chad Method: British Columbia STV
* chad Number of Ballots: 19
* chad Threshold Name: Droop Static Whole
* chad Threshold Value: 10.0
* chad Delayed Transfer of Surplus: Not Enabled.
* chad Batch Elimination: None
* chad 6 candidates running for 1 seats.
* chad  R|   A|   B|   C|   D|   S|   Y|Exha|Surp
* chad --+----+----+----+----+----+----+----+----
* RebeccaB wonders how you ask Chad how a particular person voted?
* chad  1| 0.0| 6.0| 6.0| 0.0| 5.0| 2.0| 0.0| 0.0
* chad  3|    | 6.0| 7.0|    | 6.0|    | 0.0| 0.0
* chad  4|    | 7.0| 9.0|    |    |    | 3.0| 0.0
* chad  5|    |    |13.0|    |    |    | 6.0| 3.0
* chad Round  1: Count of first place rankings.
* chad Round  2: First elimination round.
* chad           Eliminating candidadates without any votes.
* chad           Eliminating candidate A.
* chad           Eliminating candidate D.
* chad Round  3: Eliminating candidate Y.
* chad Round  4: Tie when choosing candidate to eliminate.
* chad           Tie at round 3 between B, S.
* chad           Candidate S has the fewest votes at round 2.
* chad           Eliminating candidate S.
* chad Round  5: Eliminating candidate B.
* chad           Candidate C is elected.
* chad Winner is C.

Marsh: Let's push on C. Who thinks that C is a loser?

dorchard: C is a loser because at the abstract level applications will want to know whether information is in the headers or body

<pauld> chad, list votes

sanjiva: fundementally opposed to adding headers at the headers level except from SO

[chat about STV]

<hugo> chad: B, D, S, A

[disucssio of the vote]

Marsh: formal votes on in the abstract or in the binding
... between B and C?

sanjiva: what about the SQ?

Marsh: Yes, ideally we'd vote to change the SQ first.

[marsh discusses Robert's rule of order]

Marsh: we'll vote for B and C, then vote whether to change the status quo to the winner

<Marsh> chad, options?

<Marsh> chad: what options?

<alewis> chad, remove option s

Vote B vs. C

Iona: C

W3C: B

Roguewave: B

Sun: C

<Roberto> s/Roadway/RogueWave/

UMD: Abstain

Sonic: C


Canon: C

Oracle: C

<JacekK> LFUI: C

Tibco: Abstain

SAP: Abstain

<anish> Cyclone: C


WebMethods: C

CA: Abstain


Microsoft: B


6 for B, 9 for C. C wins

Marsh: next vote: Fix and adopt C, or Status quo?

Iona: Yes

W3C: No

Rogewave: No

Sun: Yes

Sonic: Abstain

BT: Abstain

Canon: Non

<JacekK> LFUI: No

Oracle: Abstain

Tibco: No

SAP: Yes

Cyclone: Yes

Bea: Yes

CA: Abstain

IBM: Yes

Webmethods: Yes

UMD: Abstain

7 yes; 5 no: Adopt C carries

Marsh: Any lie in the roaders


Group: no

Marsh: What must we fix in option C?

Discussing: <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/att-0094/soap-header-blocks.html">http://lists.w3.org/Archives/Public/www-ws-desc/2005Jan/att-0094/soap-header-blocks.html</a>

sanjiva: my problem is that instead of using type, we use element?

(That's a scribe "?")

<Marsh> <wsoap:header element="..."/>*

marsh: is this anything more than syntax?

asir/sanjiva: yes

sanjiva: this is more consistent for the user

Marsh: acceptable to everyone?

asir: what about mustUnderstand?

<Roberto> <wsoap:header element="xs:QName" mustUnderstand="xs:boolean"? required="xs:boolean"?>*

<Marsh> <wsoap:header element="..." mustUnderstand="xs:Boolean" wsdl:required="xs:boolean"/>*

asir: goes into the binding fault and the binding reference components + new component [...]

Roberto: This goes into part 3 and we remove the AD feature from Part 1

asir: And it must be extended to the http binding

<Marsh> <whttp:header element="..." wsdl:required="xs:boolean"/>*

[some more tweaking]

asir: The whttp:header elements is avaiable to use within the SOAP HTTP binding

Marsh: We will prevent people from using HTTP headers that are already used by the protocol
... Does the working group accept these tweaks?

Group: yes

RESOLUTION: 76d is closed with the above decision

<scribe> ACTION: to asir to double check the subissues of 76d to see if they should be raised as issues and to do so


RESOLUTION: Issues 24, 53, 61f (dup of 76d) closed by the resolution of 76d

Start again at 8am tomorrow

End at 4 pm

<jjm> bye

Switched morning and afternoon schedules

H. Thompson is here from 8 to 9 about the media type note

anish: lots of editorial changes. Please check to make sure you like 'em

Meeting adjourned

Summary of Action Items

[NEW] ACTION: editors to add text along the lines suggested by David - "include a note in the spec saying that if someone combines multiple schema languages may be a problem, and we have not solved this problem"
[NEW] ACTION: editors to clarify in sec 2.1.3 and elsewhere that there be only a single element declaration in the set for each QName
[NEW] ACTION: JacekK to figure out what he thinks on this
[NEW] ACTION: Jonathan to formalize the CR criteria bag and drop "testing type system extensibility" into it
[NEW] ACTION: Jonathan will ask the WG what is the publication plan for the type system note around 3/17
[NEW] ACTION: part1 editors to check the consistency of statements related to {message content model} in the message ref component definition and the mapping table.
[NEW] ACTION: to asir to double check the subissues of 76d to see if they should be raised as issues and to do so
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.115 (CVS log)
$Date: 2005/02/15 22:31:37 $