W3C

Web Services Description WG F2F

1 Jun 2005

Agenda

Attendees

Present
Rebecca Bergersen, IONA Technologies
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
Jonathan Marsh, Chair/Microsoft
Jean-Jacques Moreau, Canon
David Orchard, BEA Systems
Arthur Ryman, IBM
Umit Yalcinalp, SAP
Observers:
Steve Winkler, SAP
Phone
Amelia Lewis, TIBCO
Bijan Parsia, University of Maryland MIND Lab
Tony Rogers, Computer Associates
Regrets
Kevin Canyang Liu, SAP
Sanjiva Weerawarana, Invited Expert
Chair
Jonathan
Scribe
anish, pauld

Contents


<anish> Scribe: anish

<scribe> Chair: Jonathan Marsh

<pauld> hugo is strongly typing

<scribe> Agenda: 7DA77BF2392448449D094BCEF67569A507B4A175@RED-MSG-30.redmond.corp.microsoft.com

Issue LC130

http://lists.w3.org/Archives/Public/www-ws-desc/2005May/0069.html

jacek: inconsistent fault defaulting in http and soap binding
... defauting on 500 http status code is a safe choice (receiver fault)
... this could be a way forward but not everyone would like it
... perhaps we should be consistent and not default

roberto: soap is different than http case we need the code so that people don't have to look at the detail element

jacek: we could also require specification of code for http as well -- another way to make it consistent

roberto: http protocol defines codes (although extensible). In soap, there could be header not understood fault in the envelope.

jacek: in http we don't need to see the code whereas in soap we do need to see the code in wsdl

jacek writes the options on the whiteboard

option 0: status quo

not required

(option 1 is like http)

option 2: default to receiver fault

option 3: code optional, if the code and subcode are missing default subcode value to fault QName and no claim is made about the fault code

option 3a: in addition, the top level code will be receiver or sender

option 4: default subcode to fault QName, code will default to receiver

<pauld> chad, question: options for LC130, binding fault defaulting

<pauld> chad, option 0: status quo

<pauld> chad, option 1: no default

<pauld> chad, option 2: default to receiver fault

<pauld> chad, option 3: code optional, if the code and subcode are missing default subcode value to fault QName and no claim is made about the fault code

<pauld> chad, option 3a: in addition, the top level code will be receiver or sender

<pauld> chad, option 4: default subcode to fault QName, code will default to receiver

option 5: @defaultFaultCode and @defaultFaultSubcode

<pauld> chad, option 5: @defaultFaultCode and @defaultFaultSubcode

<pauld> chad, question?

<pauld> chad, list options

<pauld> chad, option 5a: just @defaultFaultCode

option 5a: @defaultFaultCode but no @defaultFaultSubcode

<pauld> chad, options?

<Marsh> chad: youenn: 1, 5a, 2

<Marsh> chad: Rebecca: 4, 1, 2

<jjm> chad: 1, 5a, 2

<umit> chad: 4, 5a, 2

<hugo> vote: 1, 5a, 0, 5, 3, 4, 2

<JacekK> vote: 1, 4, 2, 3a

<Roberto> chad: 5a, 2, 4, 1, 3a, 0

<pauld> chad: 1,2

<Marsh> vote: 0, 1, 2, 4

<GlenD> chad: 4, 5a, 2

vote: 4, 2, 3a, 5a 5, 3

<Marsh> chad, count

<chad> Question: options for LC130, binding fault defaulting

<chad> Option 0: status quo (1)

<chad> Option 1: no default (5)

<chad> Option 2: default to receiver fault (0)

<chad> Option 3: code optional, if the code and subcode are missing default subcode value to fault QName and no claim is made about the fault code (0)

<chad> Option 3a: in addition, the top level code will be receiver or sender (0)

<chad> Option 4: default subcode to fault QName, code will default to receiver (4)

<chad> Option 5: @defaultFaultCode and @defaultFaultSubcode (0)

<chad> Option 5a: just @defaultFaultCode (1)

<chad> 11 voters: anish (4, 2, 3a, 5a, 5, 3) , GlenD (4, 5a, 2) , hugo (1, 5a, 0, 5, 3, 4, 2) , JacekK (1, 4, 2, 3a) , jjm (1, 5a, 2) , Marsh (0, 1, 2, 4) , pauld (1, 2) , Rebecca (4, 1, 2) , Roberto (5a, 2, 4, 1, 3a, 0) , umit (4, 5a, 2) , youenn (1, 5a, 2)

<chad> Round 1: Count of first place rankings.

<chad> Round 2: First elimination round.

<chad> Eliminating candidadates without any votes.

<chad> Eliminating candidate 2.

<chad> Eliminating candidate 3.

<chad> Eliminating candidate 3a.

<chad> Eliminating candidate 5.

<chad> Round 3: Tie when choosing candidate to eliminate.

<chad> Tie at round 2 between 0, 5a.

<chad> Tie at round 1 between 0, 5a.

<chad> Tie broken randomly.

<chad> Eliminating candidate 5a.

<chad> Round 4: Eliminating candidate 0.

<chad> Candidate 1 is elected.

<chad> Winner is option 1 - no default

option 1 is the winner

option 1 is -- no default

[discussion about what option 1 means]

roberto: we can not specify code but we have to specify subcode

jonathan: we should then say that the subcode is empty rather than not specified

umit: hate 1

roberto: we add the 'any' token for soap fault code and subcode property

<umit> i really do not see how it helps developers, users

jacek: it does resolve my issue

<pauld> chad, details

jonathan: is there anyone other than Umit who really dislikes option 1 or 4

youenn and roberto not happy 4

jonathan: there are more people who do not like 4 than people who do not like 1
... the wsubcode will be optional, wsubcode and wcode will allow #any as a token. If either those attr are missing will map to #any in the component model. #any => no assertion is made about the value

<Roberto> also wsoap:code will be optional

jonathan: with this we consider the issue closed.

roberto: can we make the http code consistent?

jonathan: yes

[everyone happy with the above]

RESOLUTION: as above

<scribe> ACTION: editors to incorporate the changes approved for issue LC130

issue LC 130 closed

issue LC89J

[discussion on namespace, symbolspace, partition etc]

jonathan: there is a context for QName ref, so it is not a problem

umit: if i have a qname in hand without the context, i don't know what it refers to

jonathan: the solutions are worse than the problem

no objection to closing LC89J with no action

RESOLUTION: LC89J closed with no action

Issue LC75x: Complete or remove App D

options listed in the agenda --

Option 0: Close issue with no action

Option 1: Remove app D

Option 2: Retitle and edit to emphasize it's far from sufficient

Option 3: Strip down to D.4 only.

Option 4: Move to primer (includes option 2)

Option 5: Add sufficient material.

jacek: don't like option 4, primer is introductory text

<Marsh> Option 3a: Strip down to D.4 and move to primer.

<Marsh> Option 6: Add sufficient material, and move to primer

umit: everyone asks about the differences

<JacekK> vote: 2, 4

jonathan: we decide that we would rely on third parties to provide the details of migration

JJ: it is a lot of work since so many things have changed

<youenn> chad, options

<pauld> chad, issue lc75x: complete or remove App D

<pauld> chad, question: issue lc75x: complete or remove App D

<jjm> vote: 6, 4

<pauld> chad, Option 0: Close issue with no action

<pauld> chad, Option 1: Remove app D

<pauld> chad, Option 2: Retitle and edit to emphasize it's far from exhaustive

<JacekK> vote: 2, 4

<Marsh> chad, Option 3a: Strip down to D.4 and move to primer.

<Marsh> chad, Option 6: Add exhaustive material, and move to primer

<pauld> chad, Option 3: Strip down to D.4 only

<Marsh> chad, Option 5: Add exhaustive material.

<pauld> chad, options?

<Marsh> chad, Option 4: Move to primer (includes option 2)

<Marsh> chad, options?

<hugo> vote: 1, 6, 5

<jjm> vote: 6, 3a, 1

<JacekK> vote: 2, 4

vote: 6, 4, 3a, 0

<Roberto> chad: 6, 4, 1, 2, 5, 3a, 0

<youenn> vote: 6, 4

<umit> chad: 1, 4, 3a

vote: rebecca: 2, 5, 1

<Marsh> vote: Tony: 5, 2

<pauld> chad: 2, 5, 1, 3

chad, list options

chad, list votes

<pauld> chad: arthur: 2,0,3, 1

<Marsh> vote: 3a, 3, 2

<Marsh> chard, count

<Marsh> chad, count

<chad> Question: issue lc75x: complete or remove App D

<chad> Option 0: Close issue with no action (0)

<chad> Option 1: Remove app D (2)

<chad> Option 2: Retitle and edit to emphasize it's far from exhaustive (4)

<chad> Option 3: Strip down to D.4 only (0)

<chad> Option 3a: Strip down to D.4 and move to primer. (1)

<chad> Option 4: Move to primer (includes option 2) (0)

<chad> Option 5: Add exhaustive material. (1)

<chad> Option 6: Add exhaustive material, and move to primer (4)

<chad> 12 voters: anish (6, 4, 3a, 0) , arthur (2, 0, 3, 1) , hugo (1, 6, 5) , JacekK (2, 4) , jjm (6, 3a, 1) , Marsh (3a, 3, 2) , pauld (2, 5, 1, 3) , rebecca (2, 5, 1) , Roberto (6, 4, 1, 2, 5, 3a, 0) , Tony (5, 2) , umit (1, 4, 3a) , youenn (6, 4)

<chad> Round 1: Count of first place rankings.

<chad> Round 2: First elimination round.

<chad> Eliminating candidadates without any votes.

<chad> Eliminating candidate 0.

<chad> Eliminating candidate 3.

<chad> Eliminating candidate 4.

<chad> Round 3: Tie when choosing candidate to eliminate.

<chad> Tie at round 2 between 3a, 5.

<chad> Tie at round 1 between 3a, 5.

<chad> Tie broken randomly.

<chad> Eliminating candidate 3a.

<chad> Round 4: Eliminating candidate 5.

<chad> Round 5: Eliminating candidate 1.

<chad> Round 6: Eliminating candidate 6.

<chad> Candidate 2 is elected.

<chad> Winner is option 2 - Retitle and edit to emphasize it's far from exhaustive

jonathan: any objection to option 2?

hugo: maybe

jonathan: option 2 does not do an exhaustive job, it lists choice morsels

anish: if someone is willing to write an exhaustive list and submit it to the editors -- that may be another way

jonathan: anyone willing to take an action to write this up/do the work?

[no one volunteered]

<pauld> chad, drop option 5

<pauld> chad, drop option 6

jonathan: lets drop 5 and 6

<pauld> chad, count

<pauld> chad, question: issue lc75x: complete or remove App D

<pauld> chad, Option 0: Close issue with no action

<pauld> chad, Option 1: Remove app D

<pauld> chad, Option 2: Retitle and edit to emphasize it's far from exhaustive

<pauld> chad, Option 3: Strip down to D.4 only

<pauld> chad, options?

<Marsh> chad, Option 3a: Strip down to D.4 and move to primer.

<Marsh> chad, Option 4: Move to primer (includes option 2)

<pauld> chad, options?

<pauld> chad: 1

<Marsh> vote: 1, 3a, 3

<hugo> vote: 1, 4, 3a, 2, 3, 0

<JacekK> vote: 2, 4

<Roberto> chad: 1, 4, 3a, 2, 0

<Marsh> Tony, 2, 0

vote: 4, 3a, 2, 3, 0

<youenn> vote: 4, 2, 3a, 0

vote: rebecca: 1

<youenn> vote: 4, 3a, 2, 0

<umit> chad: 1

<jjm> vote: 1, 4

<Marsh> vote: arthur: 2, 4, 3, 3a, 0, 1

<Marsh> chad, count

<chad> Question: issue lc75x: complete or remove App D

<chad> Option 0: Close issue with no action (0)

<chad> Option 1: Remove app D (7)

<chad> Option 2: Retitle and edit to emphasize it's far from exhaustive (2)

<chad> Option 3: Strip down to D.4 only (0)

<chad> Option 3a: Strip down to D.4 and move to primer. (0)

<chad> Option 4: Move to primer (includes option 2) (2)

<chad> 11 voters: anish (4, 3a, 2, 3, 0) , arthur (2, 4, 3, 3a, 0, 1) , hugo (1, 4, 3a, 2, 3, 0) , JacekK (2, 4) , jjm (1, 4) , Marsh (1, 3a, 3) , pauld (1) , rebecca (1) , Roberto (1, 4, 3a, 2, 0) , umit (1) , youenn (4, 3a, 2, 0)

<chad> Round 1: Count of first place rankings.

<chad> Candidate 1 is elected.

<chad> Winner is option 1 - Remove app D

option 1 wins in re-vote

<pauld> chad, hi

[break]

RESOLUTION: option 1

issue LC75c

options --

1) Status quo

2) Remove safety

3) Proposal from Umit to move safety to an extension [25]

4) Expect GET proposal from DaveO

<pauld> chad, question: LC75c, operation safety

link to option 3: http://lists.w3.org/Archives/Public/www-ws-desc/2005May/0059.html

<pauld> chad, option 1: Status quo

<pauld> chad, option 2: anti-REST

link to option 4: http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0060.html

<pauld> chad, option 3: Proposal from Umit to move safety to an extension

<pauld> chad, option 2: Remove safety

[dave explains his option 4]

<pauld> chad, option 4: Expect GET proposal from DaveO

<pauld> chad, options?

daveo: the proposal allow you to say that you must use http-get

[daveo walks thru his example in the email]

daveo: with REST operations u have few operations but lots of uri, the other way around for SOAP
... 2 aspects of proposal: adornment of interface operation with some method (eg HTTP Get) OR some generic operation names like CRUD (at the http binding READ -> HTTP-Get)
... 2 ways of modeling at the interface/operation level
... 2nd part of the proposal was to modify HTTP binding to take into consideration the changes due to 1st change
... i wud be happy to have this proposal and remove safety

Umit: what if we call safety -> CRUD, and say that the mapping to HTTP is Get for 'Safety'

daveo: it is a viable proposal, don't personally like it that much.
... if http binding was simpler and then this would be one way of doing this
... i have been arguing that these abstractions are leaky
... we can put your proposal as one of the options

roberto: i would like to make a proposal -- what dave has proposed but in wsdlx namespace
... the attribute would be defined in the adjunct

umit: the problem we are trying to solve is safety not just GET. For eg, EJBs have safe operations
... the read-only type things

roberto: i don't buy the abstract notion of safety
... by focusing on the http we can have something concrete

jonathan: jeff said that he preffered removing safety or moving it to extension

youenn: why not put it in whttp namespace

jonathan: that would sound like it bleeding thru

<pauld> chad, option 5: methods described at interface as an extension

hugo: i'm for leaving safety or dave's proposal in the spec
... for example, getstockquote is a typically example of what u should not do with POST
... i wud like to see hints for tools
... i like the CRUD stuff as it is Webby
... safe is defined in the HTTP spec
... it does not have a significant action then retrieval

daveo: u think it is fine as long it is in the core spec

<Roberto> chad, help

[some discussion on what 'safety' means in http]

umit: since we are debating about semantics and not testable, i'll modify the proposal to have wsdlx:safe and the http level it maps to GET, and move to adjunct

jacek: would it default to GET or would it be GET

Umit: it would always be GET

Roberto: when using GET it is always safe, but the other way around is not true
... u should be able to override it

Jacek: agree with roberto

Umit: I'm fine with that

jacek: it has not worked that HTTP GET is always safe

daveo: if u make a resource availble and use GET and incur obligation, then u are not using HTTP

jacek: people don't use this benefit, there are lot of broken applications
... i'm begining to lean towards dropping 'safe'

jonathan: if i click on a link i can be fired (pornography example)

Daveo: u are poking on the GET-ness, we are trying to describe the interaction, we are not designing the Web

hugo: i'm afraid that the issue of binding is going to be complex
... for http u have to have whttp:method attr unless there is a default; unless at the interface level it was 'safe'

umit: extension can do any damn thing it wants

paul: there are 2 things -- 1) marked as 'safe' -- we can know when the operation can be bound to GET, 2) message passing scenarios where it is not SOAP but say an MQ-binding -- it would be useful for intermediary to know the safe-ness to do caching.
... daveo's proposal is interesting, but safety is also very interesting

roberto: there is a big line as to whether the proposal should be in core or extension. This is about the semantics of an operation in the abstract, therefore it should be an extension. Second, safety -- just doesn't work. U also get into complicated defaulting rules. At the binding, u cannot translate safety at the abstract level to safety at the binding. The strong implication is in the different direction -- what can the tool do if it finds something at the

umit: that is my original proposal

daveo: disagree that the http-get is not about semantics it is about syntax

<pauld> +1 to daveo

daveo: HTTP-Get describes the syntax

roberto: saying that it is retrieval operation is a semantics

daveo: 2 major decision points -- what kind of solution should we use for describing http-get-ness.
... an attribute, a method (generic or http specific)
... 2nd decision point is: core or extension
... 3rd decision point: do u change your http-binding to use what we have decided in (1) and (2)
... i care most about -- it has to be part of the core, using it in the binding makes sense (but is 2nd priority). Attribute/method/CRUD -- not that concerned about.

rebeccae: i was interested in Paul's perception when using non-HTTP. was there an option to address what you wanted

paul: yes, status quo

hugo: +1 to daveo
... reusing the binding has to be carefully designed

jonathan: doesn't look like there will be consensus

paul: having interface first and then consuming that with the tools is what we are talking about

roberto: j2ee has 5th version of EJB and it still does not have it

glenn: how long is it safe? how long can i cache

paul: that is a policy thing

glenn: whether the binding is to post/get should not depend on the 'safety' thing at the abstract level

<umit> Just to be accurate, from ejb's perspective it was a "readonly" method that we tried to standardarfize but did not get it in the core spec.

paul: safety is in the web arch document so i don't see why specifying the semantics is a problem
... like satus quo

hugo: what new info is being presented

daveo: jeff is pointing out that the status quo is not very useful, either make it more useful or get rid of it

<hugo> chad, new vote

<chad> new poll

<hugo> option 1: safe, ext, w/ binding

<hugo> chad, option 1: safe, ext, w/ binding

<hugo> chad, option 2: safe, ext, w/o binding

<hugo> chad, option 3: safe, core, w/ binding

<hugo> chad, option 4: safe, core, w/o binding

<hugo> chad, option 5: method, ext, w/ binding

<hugo> chad, option 6: method, ext, w/o binding

<hugo> chad, option 7: method, core, w/ binding

<hugo> chad, option 8: method, core, w/o binding

chad, question: which option do u prefer?

<hugo> chad, option 9: drop the safety completely

<pauld> chad, list options

<Marsh> chad: amy: 9,7

<JacekK> vote: 9, 1, 3, 2, 4

<pauld> chad: arthur: 7,8,3,4,5,6,1,2

<Roberto> chad: 9, 5, 6, 2, 1, 4, 3, 8

<hugo> Note that status quo is #4

<pauld> chad: 7,8,4,3,5,6,1,2

vote: 1, 2, 5, 6, 9, 4

<youenn> vote: 4, 2, 1, 9

vote: rebecca: 9, 4, 2, 1

<Marsh> 9, 4, 2

<Marsh> chad: tony: 9

vote: daveo: 7, 3, 8

<jjm> vote: 9, , 4

chad, options

chad, votes

<umit> chad: 9, 2, 1, 5

<Marsh> vote: 9, 4, 2

<hugo> vote: 4, 7, 3, 8, 5, 2, 1, 6

<Marsh> chad: count

<Marsh> chad, count

<chad> Question: which option do u prefer?

<chad> Option 1: safe, ext, w/ binding (1)

<chad> Option 2: safe, ext, w/o binding (0)

<chad> Option 3: safe, core, w/ binding (0)

<chad> Option 4: safe, core, w/o binding (2)

<chad> Option 5: method, ext, w/ binding (0)

<chad> Option 6: method, ext, w/o binding (0)

<chad> Option 7: method, core, w/ binding (3)

<chad> Option 8: method, core, w/o binding (0)

<chad> Option 9: drop the safety completely (8)

<chad> 14 voters: amy (9, 7) , anish (1, 2, 5, 6, 9, 4) , arthur (7, 8, 3, 4, 5, 6, 1, 2) , daveo (7, 3, 8) , hugo (4, 7, 3, 8, 5, 2, 1, 6) , JacekK (9, 1, 3, 2, 4) , jjm (9, 4) , Marsh (9, 4, 2) , pauld (7, 8, 4, 3, 5, 6, 1, 2) , rebecca (9, 4, 2, 1) , Roberto (9, 5, 6, 2, 1, 4, 3, 8) , tony (9) , umit (9, 2, 1, 5) , youenn (4, 2, 1, 9)

<chad> Round 1: Count of first place rankings.

<chad> Candidate 9 is elected.

<chad> Winner is option 9 - drop the safety completely

jonathan: are there folks who cannot live with 9?

[few hands raised]

<JacekK> vote: 1, 3, 2, 4

<Roberto> chad: 5, 6, 2, 1, 4, 3, 8

<Marsh> vote: 4, 2

<umit> chad: 2, 1, 5

<Marsh> chad: tony:

vote: 1, 2, 5, 6, 4

<Marsh> chad: tony: abstain

vote: rebecca: 4, 2

<youenn> vote: 4, 2, 6, 8

<Marsh> chad: amy: 7

<GlenD> vote: 4, 2, 1

<jjm> vote: 4, 2

<Marsh> chad, count

<chad> Question: which option do u prefer?

<chad> Option 1: safe, ext, w/ binding (2)

<chad> Option 2: safe, ext, w/o binding (1)

<chad> Option 3: safe, core, w/ binding (0)

<chad> Option 4: safe, core, w/o binding (6)

<chad> Option 5: method, ext, w/ binding (1)

<chad> Option 6: method, ext, w/o binding (0)

<chad> Option 7: method, core, w/ binding (4)

<chad> Option 8: method, core, w/o binding (0)

<chad> Option 9: drop the safety completely (0)

<chad> 15 voters: amy (7) , anish (1, 2, 5, 6, 4) , arthur (7, 8, 3, 4, 5, 6, 1, 2) , daveo (7, 3, 8) , GlenD (4, 2, 1) , hugo (4, 7, 3, 8, 5, 2, 1, 6) , JacekK (1, 3, 2, 4) , jjm (4, 2) , Marsh (4, 2) , pauld (7, 8, 4, 3, 5, 6, 1, 2) , rebecca (4, 2) , Roberto (5, 6, 2, 1, 4, 3, 8) , tony () , umit (2, 1, 5) , youenn (4, 2, 6, 8)

<chad> Round 1: Count of first place rankings.

<chad> Round 2: First elimination round.

<chad> Eliminating candidadates without any votes.

<chad> Eliminating candidate 3.

<chad> Eliminating candidate 6.

<chad> Eliminating candidate 8.

<chad> Eliminating candidate 9.

<chad> Round 3: Tie when choosing candidate to eliminate.

<chad> Tie at round 2 between 2, 5.

<chad> Tie at round 1 between 2, 5.

<chad> Tie broken randomly.

<chad> Eliminating candidate 2.

<chad> Round 4: Eliminating candidate 5.

<chad> Round 5: Tie when choosing candidate to eliminate.

<chad> Tie at round 4 between 1, 7.

<chad> Candidate 1 has the fewest votes at round 3.

<chad> Eliminating candidate 1.

<chad> Candidate 4 is elected.

<chad> Winner is option 4 - safe, core, w/o binding

can't live with option 9: 4

can't live with option 1: 1

can't live with option 1: 2

can't live with option 2: 3

can't live with option 3: 4

can't live with option 3: 3

can't live with option 4: 4

can't live with option 5: 2

can't live with option 6: 2

can't live with option 7: 4

can't live with option 8: 4

can't live with option 9: 4

hugo: one thing that is important is that the TAG has asked us to do this
... it is important to point out that there are situations where u should use HTTP-Get and it should be usable out-of-the-box and therefore in the core

umit: what about soap binding? the status quo does not say anything

jonathan: the original issue is addressed by 9, 2, 4 options

hugo: we feel strongly about not making it an extension but it is better than removing it completely

jonathan: option 2 is the option that has least objections AND addresses the LC comment

daveo: don't like option 2 -- worst of all options
... like option 1 better than option 2

glen: it is in core but nothing is defined about it, so u have to define an extension to make it work

daveo: we got asked to do something and we decide not to do it, this is brinkmanship

roberto: i would like to do it as an extension

jjm: in XMLP we did not support the web property and had to create a special MEP

jonathan: but no one uses that MEP

daveo: status is something like what XMLP did, provides the minimal thing but nothing useful, to get away

paul: safety is useful beyond HTTP

glen: is this anything more than cache?

paul: basically

<jjm> jjm: yes, that was my point, nobody uses the SOAP Get MEP

[lunch-break]

<pauld> scribe: pauld

<scribe> Scribe: pauld

The Future of F2F Meetings

marsh: we have no meetings scheduled
... co-location with addressing in july has been difficult to arrange
... suggest 2x 4 hour telcons

daveo: so long as that's not near travelling to other F2Fs, e.g addressing

umit: noone else can host in NYC at the same time as addressing?

daveo: depends upon space availability at IBM

marsh: physical F2F best for me at start of August

bashing of dates

chad on standby

hugo: July 14th is BH in France

Marsh: 12-13th July?

4th of july is fine by me :-)

will discuss with Addressing re co-location, otherwise we'll go for a telcon

Operation Safety, Continued

Hugo: daveo and I feel strongly it should remain in the core, but more strongly shouldn't be removed
... has a proposal:
... 1) put safety in its own namespace
... 2) modify the HTTP binding defaulting rules to say that if no method is speciified and the @ext:safety attribute is used in the operation, then the method is GET

anish: expect LC comments on this being inconsistant

marsh: i'd worry this would be used to provide a default method in the HTTP binding

hugo: that's a side-effect

umit: my proposal says wsdlx namespace

marsh: method attribute would become optional?

hugo: it is already, there is a default on the binding

rebecca: what happens if you have safe attribute and no HTTP binding

umit: status quo allows that

tonyr: want's to change the name
... idempotent or whatever

pauld: take your comments to the TAG and IETF. it's their term

arthur: +1 to paul

tonyr: when we resolve this, what will it mean?

marsh: we argued about this long and hard (before you joined the group).
... any objections to adopting proposal 1?
... we have concensus!

RESOLUTION: close last call issue 75c with hugo's proposal, moved to the adjunct spec

<scribe> ACTION: Jonathan to draw the optionality of the safe attribute to the TAG's attention

LC114

raised by dbooth on behalf of Shlomo Cwang

glen: you can do this with extensions, including defining your own MEP

marsh: anyone planning to implement such MEPS?

glen: Axis 2 will support user defined MEPs

RESOLUTION: close LC114 with no action

LC79/LC102

Glen: expands on status of async-tf. nothing conclusive, yet
... would like to walk through options currently being discussed

marsh: concentrate on issues for WSDL

umit: there is a need for a SOAP in-only MEP - lets concentrate on issues 102 and 79

marsh: WG needs some context

glen: first issue is how many MEPs do we need?

marsh: we need one or more

anish: lots of issues related to 'async' only one related to WSDL: do we allow WSDL MEPs to use one or more SOAP MEPs

glen: the wsa in play marker changes the semantics of WSDL at will

anish: i would hope that people don't create extensions to change WSDL willy-nilly
... two cases: SOAP request response, wsa:using modifies the binding to allow the SOAP req-response binding over two HTTP connects (that's OK). but if the SOAP req-response ends up as 2 SOAP one-ways, that would make me unhappy

glen: i don't think that's going to happen

umit: third possibility, one request-response MEP, could be exhibited by two operations

glen: you could define an entirely new HTTP binding, but i don't think we need to go that far.

daveo: one WSDL MEP maps to one SOAP MEP, it looks the same in WSDL?

glen: and then there are transport MEPs

daveo: doesn't like the multi-connection-HTTP binding, is it's harder to write than two, one-way bindings

anish: you could write a binding in which the request and response always goes over separate connections

glen: doesn't like this, too specific to HTTP

daveo: doesn't solve the world's problems, but solves one problem well.. writing the two way binding is much harder

anish: if we go down this route we have to account for overlaps, it gets hard

daveo: expands on complexity of writing protocol bindings

glen: pops up. the question is do we do this work under one SOAP MEP or by using multiple SOAP MEPs?

roberto: do you mean WSDL MEPs in the abstract?

glen: yes

umit: the decision tree has been layed out, and we have made concrete proposals, but the descision has yet to be made

roberto: how much of this is WSDLs concrete binding's fault. what if we had separate protocol and transport bindings?
... it's a problem of the granularity of binding

umit: it's an artifact of how SOAP was designed

anish: defends SOAP

glen: SOAP MEPs specifically designed for other transport bindings to be built easily based upon SOAP MEPs

anish: from a WSDL pov we should pick one (initial) way to flesh out

tonyr: the one we expect people to use most often ?

anish: yes

daveo: if the community, decides to provide a single MEP to MAP to multiple SOAP MAPs, then what happens in WSDL 1.1?

anish: 1) do we allow this out of the box 2) do we allow out of the box to use two different transports?

roberto: all sounds very important, what's the use-case we're trying to resolve here

daveo: wrote up some scenarios

pauld: using my diagrams :-)

roberto: ok you have a taxonomy, but what do people want to do?

umit: request-response over two HTTP connections

glen: sonic want's to use multiple transports
... we need to decide on our approach, piecemeal or fully formed

umit: it's a top level descision.

anish: what do people want?

marsh: to close the issue!
... this has gone on for some time, where is the concrete proposal?

daveo: one design point is one-way SOAP MEP and one-way binding to get async MEP wsa then triggers two one WSDL MEP spliting into two SOAP MEPs. Addressing has to say something for protocol switch, no changes to WSDL
... one-way MEP and one-way binding, and then WSDL provides this out of the box

discussion gets interesting, but scribe can't keep up :-(

daveo: what happens if we provide a one-way MEP and binding and addressing doesn't use it?

marsh: we're not chartered to deliver a one-way binding, all we can do is encourage someone else to deliver this for us

daveo: somebody needs to do this, we need some coordination between the WGs. close this issue and get somebody else to do it.

umit: what URI is arthur going to put in the his test cases?

hugo: we already decided to remove MEPs we couldn't test in CR

glen: extension could be published elsewhere, test description is not a rec track document

daveo: CG already aware of this issue

umit: we need to put it on their agenda

daveo: want's to go back to LC79 and LC102 issues
... if XMLP came up with a one-way MEP and one-way binding, would we need to keep this issue open to build upon them ?

glen: worries about the timing

marsh: worst case you'd have to write more URIs in the binding

daveo: we can't go to REC if we want a default value for a one-way binding

umit: it has to have a value, we should at least define it as a placeholder

glen. marsh: when one is defined, then you can use it

marsh: i have a problem putting a forward reference to a spec not on anyone's workstack. we can only depend upon specs one stage behind us.

daveo: maybe we're screwed already

glen: it's not our job to specify everything in the world

umit: in-only is a pretty basic thing

glen: we can reference notes and other non-recs from specs, we have precidence

marsh: only for optional aspects, default isn't like that

daveo: we should ensure addressing's CR includes this scenario, maybe we could coordinate our CR with theirs?

marsh: we need to close issues; inform the CG; if it is done soon, we could depend upon it and improve our defaulting mechanism

daveo: we should close these issues and expect to open an issue if this MEP arrives

marsh: suggests an editorial note in the spec

pauld: this is a management problem, TF isn't empowerded to solve this
... coordination across three WGs requires CG

anish: XMLP has yet to receive a formal request from WSDL WG

marsh: that's what we'd do via the CG, but our requirements aren't clear
... will warn the CG of incoming requirements

<scribe> ACTION: marsh to warn CG of incoming requirements for async MEP

<scribe> ACTION: glen to formulate concrete async requirement for CG

umit: fulminates

RESOLUTION: Close issues 79 and 102 by sending request to CG for one-way MEP and adding an ednote to the spec saying that if a one-way MEP becomes available, we'd like to default to it for in-only.

break

LC98

glen: discusses accepting Asir's proposed solution, but do we need something similar for SOAP 1.1?

hugo: we already have some text for this

discussion of soap 1.1 binding text and reference to WS-I Basic Profile

marsh: we need to appoint a new editor for this document (now we've lost Asir)

glen: answer to my question seems to be no

marsh: binding only for two MEPs

<scribe> ACTION: soap 1.1 binding editors to make MUST and SHOULD lower case in the Note on in-only MEPs

RESOLUTION: close LC98 with Asir's proposal

LC101

Glen: has two proposals on this issue:
... 1) extension in the SOAP binding (close to Status Quo)
... 2) bind on a per-message level as opposed to per-operation
... there may be other use-cases for per-message binding

marsh: e.g. non-secure in, secure back

glen: at runtime, wsa could switch bindings for the output message

<umit> iow, it is dynamic binding of bindings

glen: middle ground could be statically saying HTTP, in then one or more different transports back

pauld: alternative is to write a HTTP-in, SMTP-out binding, ugh!

marsh, glen: combatorial explosion

glen: could be two operations in two interfaces, choreography required

<umit> not really choreography, but some kind of correlation.

<umit> that incorporates two different operations

arthur: probably best to have separate operations

roberto: long running interactions, you'd probably want compensating transactions, etc. shurely separate operations natural

anish: long lived interaction is not unique to separate protocols.

glen: 1 isn't sufficient to solve the entire problem

roberto: (to glen) sounds like you're trying to go too far. in concrete terms may not be so useful. semantics could be placed at the application level

umit: we had similar feedback internally

paul: cites line-test use-case where same operation bound to HTTP, but may be called HTTP, reply SMTP. service may switch bindings dependent upon how long the test takes

glen: expounds on the use-case

discussion drifts into discussion of meta-bindings

roberto: so nothing concrete, operations point to other operations

glen: work needs to be done, but we don't need to hold WSDL 2.0 schedule - we can use extensibility

marsh: cheers!

<umit> +1

RESOLUTION: close LC101 with no action

LC74c

arthur: roberto wanted to think some more on this
... annotation has documentation and appinfo

umit: why can't we just follow schema? proposes introducing appinfo

roberto: schema doesn't have an open content model (apart from attributes)
... atom has a documentation type attribute, it's text, html, xhtml etc

marsh: you mean CDATA HTML?
... stretching the bounds of this issue

arthur: our spec says machine-readable already and you can add lang attributes today. you can create a wrapper element with the lang tag

anish: XMLP solved a similar issue for fault detail. we could add text to say human readable text should have a lang attribute

roberto: wouldn't you want a WSDL enabled browser to show HTML nicely?
... reader would require heuristics to detect HTML.

arthur: in practice, XHTML would be used

hugo: like anish, we should specify use of xml:lang for documentation. No need to go much further.

marsh: xml:lang='' means no assertion on language. no attribute means it will be inherited from elsewhere further up

arthur: happy with the proposal
... should documentation be in a single language?

marsh: you can compose documentation from multiple languages, e.g. quote latin

tonyr: use-case in UDDI to have several documentation sections in the same language

hugo: raises Amy's proposal to add anyAttribute namespace=##other

tonyr: lang, are they required to be unique?

marsh: we're not going there

RESOLUTION: close LC74c with Amy's proposal and text to suggest using xml:lang attribute

pauld: outlines motivation for proposal - versioning's last stand
... would prefer to have this baked into wsdl, and not ignore content as the flag

daveo: flag in extensibility would trigger this

umit: what spec would we be referencing?

roberto: why isn't this a schema WG issue
... it's great, why are we doing this here?

marsh: well we have wsdl:required

roberto: could do this through a profile

pauld: is there something special about WSDL's use of schema ?

roberto: would be neat to be able to do this for XML in general

marsh: is this an extensibility point, open or are we going so far as to specify Henry's proposal

daveo: 2nd

glen: whay can't we just kick this out to extensibility

marsh: we could just use another type system, e.g. RelaxNG

daveo: we're not throwing out schema, it's still schema

roberto: it's not the same validation rules, there is extra processing

marsh: it's essentially a different type system

daveo: it's a valid use of schema

roberto: it's a refinement of the validity relationship

pauld: it's a superset

glen: why do we want an extensibility point rather than a henryValidation='true'

umit: how much experience have we of this technique?

pauld: decades of using the must ignore rule

umit: cites f(x) = boolean f'(x) = boolean

pauld, daveo: output is a PSVI, not boolean

marsh: do we want a flag or an extensibility point

tonyr: paul's document suggests an extensibility point

pauld: wants something the WG can agree upon, happier with a henry='true' markup

marsh: all done, thanks to SAP for hosting

<hugo> ADJOURNED

Summary of Action Items

[NEW] ACTION: editors to incorporate the changes approved for issue LC130
[NEW] ACTION: glen to formulate concrete async requirement for CG
[NEW] ACTION: Jonathan to draw the optionality of the safe attribute to the TAG's attention
[NEW] ACTION: marsh to warn CG of incoming requirements for async MEP
[NEW] ACTION: soap 1.1 binding editors to make MUST and SHOULD lower case in the Note on in-only MEPs
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.126 (CVS log)
$Date: 2005/05/16 16:49:48 $