<anish> Scribe: anish
<scribe> Chair: Jonathan Marsh
<pauld> hugo is strongly typing
<scribe> Agenda: 7DA77BF2392448449D094BCEF67569A507B4A175@RED-MSG-30.redmond.corp.microsoft.com
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
[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
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
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
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
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
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
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
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
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
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