W3C home > Mailing lists > Public > www-ws-desc@w3.org > July 2004

Minutes, 8 July 2004 WS Desc telcon

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Thu, 8 Jul 2004 11:32:50 -0700
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA2043058D7@RED-MSG-30.redmond.corp.microsoft.com>
To: <www-ws-desc@w3.org>

Web Service Description Working Group
8 July 2004 telcon

Present:
 Erik Ackerman          Lexmark
 David Booth            W3C
 Allen Brookes          Rogue Wave Software
 Ugo Corda              SeeBeyond
 Glen Daniels           Sonic Software
 Paul Downey            British Telecommunications
 Youenn Fablet          Canon
 Martin Gudgin          Microsoft
 Hugo Haas              W3C
 Tom Jordahl            Macromedia
 Jacek Kopecky          DERI
 Amelia Lewis           TIBCO
 Kevin Canyang Liu      SAP
 Peter Madziak          Agfa-Gevaert N. V.
 Jonathan Marsh         Chair (Microsoft)
 Jeff Mischkinsky       Oracle
 Dale Moberg            Cyclone Commerce
 Jean-Jacques Moreau    Canon
 David Orchard          BEA Systems
 Jeffrey Schlimmer      Microsoft
 Jerry Thrasher         Lexmark
 Asir Vedamuthu         webMethods
 Sanjiva Weerawarana    IBM
 Umit Yalcinalp         Oracle
 Prasad Yendluri        webMethods, Inc.

Regrets:
 Roberto Chinnici       Sun Microsystems
 Mark Nottingham        BEA Systems
 Bijan Parsia           University of Maryland MIND Lab
 Arthur Ryman           IBM


--------------------------------------------------------------------
Agenda

1.  Assign scribe.  Lucky minute taker for this week is one of:
      Adi Sakala, Umit Yalcinalp, Igor Sedukhin, Dale Moberg, 
      Paul Downey, Hugo Haas

Paul Downey

--------------------------------------------------------------------
2.  Approval of minutes:
  - July 1 [.1] 

[.1] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0257.html

Approved

--------------------------------------------------------------------
3.  Review of Action items [.1].
PENDING   2004-04-01: Marsh will get schema tf going.
?ED       2004-05-19: Editors to include in the primer an example 
                      that uses MTOM.  (Issue 72) 
?ED       2004-05-20: Editors to incorporate Hugo's full potato 
                      proposal.  (Issue 54)
?ED       2004-05-20: David Orchard to update HTTP binding to 
                      include discussion of how to generate an 
                      accepts header from schema annotations 
                      conformant to the media types extension 
                      document, and to use outputSerialization 
                      based on that information.  
?ED       2004-05-21: Editors to add ednotes to the spec to 
                      indicate areas that had contention.  (Issue 
                      190)
DONE? [.10] 2004-05-21: DaveO to write up a scenario to motivate path
                      creation on a per-operation basis.  (Issue 
                      190)
?ED       2004-05-27: Editors to add http:faultSerialization 
                      attribute.
DONE [.10] 2004-05-27: DaveO will write up better description of 
                      this issue (189).
?ED       2004-06-10: Editors should correct issues 208, 213, 
                      215, come back to WG if there are any 
                      questions.
DONE [.5] 2004-06-17: Editor action to check that multiple style 
                      values are allowed.
DONE [.5] 2004-06-17: Editors to adopt Mark's proposal for 216, but 
                      reword using MUST.
DONE [.5] 2004-06-17: Editors to incorporate editorial fix addressing 
                      issue 222.
DONE [.5] 2004-06-17: Editors to incorporate proposed resolution for 
                      223 and 224.
?ED       2004-06-17: Editors to incorporate David Booth's clarification
                      in section 8.3 about what required means on MTOM
                      feature.
DONE [.11] 2004-06-24: David O will update his proposal for adding 
                      async capability.
DONE [.3, .5] 2004-06-24: [Roberto] to synchronize specs, schema, 
                      pseudo-schema on where f&p can appear.
?ED       2004-06-24: Editors to incorporate Jonathan's resolution 
                      to issue 160. 
?ED       2004-06-24: Editors to fix media-type reg frag id link, 
                      per 209.
DONE      2004-07-01: JMarsh to explore Nov 10-12.
DONE [.2] 2004-07-01: DBooth to provide a sample (<x-specref>?)
?ED       2004-07-01: Editors to add cross-references for component
                      properties, per DBooth's example.
DONE      2004-07-01: Editors to add note pointing out that our SOAP 
                      binding only allows a single element in the 
                      body.
DONE [.4] 2004-07-01: Umit to write up a proposal on 168 by weekend.
DONE [.9] 2004-07-01: JMarsh to contact DaveO on whether issue 195 is 
                      on composition model or on developing a language.
DONE      2004-07-01: DBooth to add sentence in the primer (per issue 
                      197) saying that the scoping rules for 
                      requiredness allow the value of the @required 
                      attribute to be changed, and therefore the 
                      writer should consider whether it is wise to 
                      change a value that was set elsewhere by someone 
                      else.
DONE      2004-07-01: Editors to incorporate Mark's proposals 
                      2004Jun/0195.html and 2004Jun/0199.html, and 
                      a reference to the charmod (Issue 210) 
DONE [.8] 2004-07-01: Mark to reword his proposal on 211 to make it 
                      more readable.
DONE      2004-07-01: Editors to incorporate solution proposed in
                      2004Jun/0276.html including Mark's amendment, 
                      plus note that errors are an open set. 
                      (Issue 218)
DONE      2004-07-01: Editors to include or import defn of "actual 
                      value" from XML Schema. (Issue 219) 
DONE [.7] 2004-07-01: MarkN to start a thread on 220 with the intent 
                      to get a proposal by next week.
DONE [.5] 2004-07-01: Editors to incorporate Mark's proposal #1, with 
                      ed license (see Roberto's suggestion) (Issue 
                      225).
DONE [.6] 2004-07-01: MarkN to investigate type wording, to ensure 
                      non-infoset type systems are allowed in 
                      <types>  (Issue 225 part 2).

[.1] http://www.w3.org/2002/ws/desc/#actions
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0018.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0014.html
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0037.html
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0059.html
[.6] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0050.html
[.7] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0049.html
[.8] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0047.html
[.9] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0022.html
[.10] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0061.html
[.11] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0287.html

---------------------------------------------------------------------
4.  Administrivia
  a. - August 2-4 (London)
       Logistics [.1], registration [.2].
     - September 14-16 (Toronto) [.3]
     - November (West Coast) 8-10 webMethods Sunnyvale, CA.
       Poll on moving to 9-11 [.4]

poll for dates for Nov F2F closes Sunday
results on Monday

  b. XMLP WG response to our comments [.5, .6]
     - Postpone till next week.

postpone talking to XMLP until next week

[.1] http://www.w3.org/2002/ws/desc/4/04-08-f2f.htm
[.2] http://lists.w3.org/Archives/Member/w3c-ws-desc/2004Mar/0064.html
[.3] http://lists.w3.org/Archives/Member/w3c-ws-desc/2004May/0000.html
[.4] http://lists.w3.org/Archives/Member/w3c-ws-desc/2004Jul/0008.html
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0036.html
[.6] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0006.html

------------------------------------------------------------------
5.  Task Force Status.
 a. Media type description
  - 1st Working Draft Published [.1]
 b. MTOM/XOP
  - Last Call Published [.2]
 c. QA & Testing
  - Suggested QA plan [.3]
  - More details from Arthur [.4]
  - Interop bake-off
 d. Schema versioning
  - Waiting to hear back from Schema on my draft "charter."
  - Henry's validate-twice write-up [.5]

[.1] http://www.w3.org/TR/2004/WD-xml-media-types-20040608/
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0052.html
[.3]
http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/att-0029/QA_Oper
ational_Checklist.htm
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0037.html
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0019.html

------------------------------------------------------------------
6.  New Issues.  Issues list [.1].
  - Consistent placement of <feature> and <property> (Sanjiva) [.2]
  - Editorial issues with Part 3 (Hugo) [.3]
  - MTOM/XOP support (Umit) [.4]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0267.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0011.html
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0038.html

------------------------------------------------------------------
7.  Editorial issues:
  - In the hands of the editors:
    208 Misc. editorial comments 
    213 Refine component model property constraints 
    215 Clarify rule obviation
  - Proposed to go directly to editors without further discussion:
    227 Description of Binding Operation component
    235 Definition of Fault 
    231 Clarify "patterns" 
    232 Differentiate our MEPs from underlying protocol MEPs [.1]
    234 Ruleset terminology
    226 Cross-binding HTTP features

[.1] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0030.html

Marsh:  Anybody object to making these issues editorial?
No objection.
RESOLUTION: Issues 227, 235, 231, 232, 234, 226 referred to editors.
ACTION: Editors to deal with issue 227, come back to the WG 
        with issues if any.
ACTION: Editors to deal with issue 235, come back to the WG 
        with issues if any.
ACTION: Editors to deal with issue 231, come back to the WG 
        with issues if any.
ACTION: Editors to deal with issue 232, come back to the WG 
        with issues if any.
ACTION: Editors to deal with issue 234, come back to the WG 
        with issues if any.
ACTION: Editors to deal with issue 226, come back to the WG 
        with issues if any.

------------------------------------------------------------------
8.  Issue 177: Normative dependence on XML Schema 1.0 precludes 
               XML 1.1 [.1]
  - Jonathan's proposal [.2]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x177
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0258.html

Umit:   All WSDL processors must be able to accept XML 1.1 documents?
Marsh:  Friendly amendment XML 1.1 is not a conformance requirement
Umit:   Why not rev WSDL for XML 1.1? We have to think what 
        conformance really means for XML versions - we'll have to 
        rev the spec anyway when we get new version of schema
Marsh:  Nothing we have to do for LC to promise to rev in the 
        future, any questions on my proposal?
Asir:   Can't we raise a LC issue#1 on this issue and await the 
        outcome from the schema WG.
Tom:    Likes Jonathan's proposal
dbooth: If accepted, we should flag this at risk dependent upon 
        the findings of the schema 1.1 WG
Marsh:  Any objections to adopting my proposal?
Umit:   Sounds OK so far, but i would like to see this written down
Marsh:  We need to adopt this (or not) today, not willing to keep 
        the issue open longer.  Is the amendment clear?
Straw Poll: Adopt 177 with amendments
<Marsh> Yes: 18; 2 Nos (Oracle)
Marsh:  Do we have consensus?
yes
RESOLUTION: close issue 177 with Jonathan's modified proposal.
<Marsh> ACTION: Editors to implement resolution to 177 as amended.

------------------------------------------------------------------
9.  Issue 228: Should f&p be allowed in more places? [.1]
  - Proposal to allow f&p on Interface Faults, Binding Faults, 
    and Fault References [.2]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x228
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0039.html

Glen:   We should document the scope for each place we allow a feature
Marsh:  Any objections to adopting this proposal?
<Marsh> Kevin, Tom, Microsoft object.
Straw Poll - adopt proposal for issue 228?
* sanjiva votes yes because even if we are doing something wrong its
good to do it wrong all over consistently rather than haphazardly :-(
<Marsh> Yes: 11, No: 4 (Kevin, Tom, Gudge, JeffSch), Abstains: 7
Marsh: Any objections to recording consensus?
(no)
RESOLUTION: Close issue 228 by adding f&p to Interface Faults, Binding
Faults, and Fault References.
ACTION: Editors to implement resolution to 228
<Marsh> ACTION: Glen to verifiy composition model.

------------------------------------------------------------------
10. Issue 195: Property value merging [.1]
  - We have a property composition model [.2]
  - We don't have a language that helps navigate properties [.3]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x195
[.2]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?cont
ent-type=text/html%3B0charset=utf-8#Property_composition_model
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0040.html

RESOLUTION: close issue 195 with no action.

------------------------------------------------------------------
11. Issue 112: New headers/body style? [.1]
  - AD feature proposal (Dave, Glen, Yaron) [.2]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x112
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0225.html

Asir:    Has question on the list re: mustUnderstand, 2nd 
         question - where does this proposal fit (part 4 or note?)
DaveO:   First part in part1, then specific features in part3
Marsh:   Note means we don't have to write this for LC
Glen:    Some of this is normative, right?
<dbooth> q+ to note that this would be defining an extension that 
         anyone could define and ask if the AD proposal fills an 
         80/20 need
<jeffsch> What is "part 4"?
<asir>   adjuncts
<Marsh>  jeffsch: a myth
<asir>   collection of built-in features and properties
Glen:    Is this just normative or required of all WSDL processors?
<jeffsch> How many "mandatory" features are currently being proposed?
DBooth:  A note puts it at the status of any other extension - does 
         this fill 80/20 need to be in the core spec?
<Gudge>  didn't we already *remove* a way to specify headers? (in
Virginia)
<sanjiva> yes we did .. now we're considering putting them back
         as a required feature!
<umit>   we have made the agreement based on the promise that we 
         will address ADD. Otherwise, this decision would not be reached
dbooth:  'required' for an extension flags up interoperability problems
Glen:    Having one mechanism standardised here improves
interoperability 
<TomJ>   I didn't like the fact that we removed header in the first
place!
Sanjiva: Doesn't understand concept of having 'required features'
<jeffsch> +1 to Sanjiva that _extensions_ should not be mandatory
Glen:    Make it a feature rather than a language thing which may be 
         too locked down
<jeffsch> What is the concern if the feature is not mandatory? 
         That some WSDL authors won't see the value of the feature 
         and fail to use it?
<dbooth> A "required extension" is merely a convenient way for the
         WSDL spec writers to define a normative part of the spec.
Sanjiva: Why use extensibility mechanism to define required language
<jeffsch> What is the risk of making any feature non mandatory?
Umit:    We're here because we removed the ability to describe headers 
Sanjiva: Either we have AD as an optional extension, or we have 
         'headers' directly in the language
<TomJ>   I would support putting headers back in the language - 
         +1 to Sanjiva
daveo:   are you making a proposal, Sanjiva?
<sanjiva> I don't recall having an agreement that removing headers 
         meant that the AD feature would be a required thing. 
Sanjiva: No, we've already removed headers and doesn't like "required 
         feature"
<prasad> I would support putting headers back as well. Then we can 
         nail the operation name issue via a header! Which is the 
         right soln IMO :)
<umit>   I would support it as well. 
Glen:    "required feature" means binding will engage the appropriate 
         SOAP module
<jeffsch> On which WSDL construct would the proposed 'feature' go?
<dbooth> Straw poll 1: Should the ADD Feature be required of all 
         conformant WSDL processors?
Glen:    Required by default (only need property declaration), or not
<sanjiva> Jeff: I think it goes on <operation> .. but one of the 
         proponents should indicate where it goes. The proposal 
         doesn't seem to make that clear.
Asir:    Suggest modification - add concept of builtin (predefined)
features 
Marsh:   This is basically the intent of proposal
daveo:   mustUnderstand should be in the abstract defined at the \
         interface level.
Glen:    Why in the WSDL?
<jeffsch> Would the proposed 'feature' go on
wsdl:interface/wsdl:operation?
Glen:    Versioning?! seems a little wierd when you've built an 
         incompatible extenstion?
<jeffsch> Why would one indicate a SOAP header in wsdl:interface 
         (versus wsdl:binding)?
Glen:    Why not just change the interface and do the whole thing?
DaveO:   Well why do we need or even have soap:mustUnderstand?
Glen:    mustUnderstand only applies to headers (implicit on whole body)
DaveO:   The client might not control the qname of the soap body.
         Distributed extensibility
<asir>   suggestion: split the question - add proposal, mU, role, ..
Amy:     soap:mustUnderstand in the body?
DaveO:   Client doesn't control the description of the body - client 
         has to use soap extensibility mechanism to extend the message
<dbooth> Straw poll v2: Should we adopt the proposed AD Feature (which 
         MUST be supported by all conformant WSDL processors)?
Sanjiva: Wonders how abstract mustUnderstand maps to other bindings
<GlenD>  glend wonders how bodies with arbitrary XML map to other 
         bindings :)
Marsh:   Suggest adopting this proposal and moving mustUnderstand to 
         another issue
<jeffsch> GlenD: Agreed. AD is a 'how much more' argument.
Umit:    There was a friendly amendment for an abstract MU
DaveO:   Liked the ad:mustUnderstand amendment
Asir:    Doesn't like mustUnderstand and role in the interface
<Marsh>  Straw poll: amend proposal to remove mustUnderstand and role
<jeffsch> Given the trouble we have binding rich 'body' to non-SOAP 
         bindings, how much more trouble will we have binding 
         'header' to non-SOAP bindings?
<sanjiva> if you can make the requiredness go away I'll support 
         this .. to me having a required feature doesn't make sense 
         in general and, in this particular case, its basically 
         syntactic alternate for @headers which we removed.  So 
         I'd suggest a friendly amendment to make it not be required.
<jeffsch> How should one vote on the straw poll if one does not 
         support the proposal as a whole?
<GlenD>  jeff - abstain, I'd guess, then vote no on the 2nd one
<umit>   That is not a friendly amandement Sanjiva :-)
<sanjiva> ok ;-) then you know my vote!
<dbooth> Straw poll v2: Should we adopt the proposed AD Feature 
         (which MUST be supported by all conformant WSDL processors)?
<jeffsch> Is the 'friendly ammendment' of Sanjiva in play, that 
         it be made not required?
<Marsh>  Yes: 6, No: 6, Abastain: 9
<GlenD>  as did Sanjiva
Straw Poll: publish by this WG as a feature - not required for a 
         conformant processor
<Marsh> Yes: 14; 5 Nos, 3 abstain
<DaveO> so we went from a required soap:header, which we got rid 
        of because of AD, to an optional feature.  yuck.
<sanjiva> Its a feature DaveO .. and you can mark it required if 
        you want. 
<umit>  yuck too.
<jeffsch> FWIW, I will still vote against the proposal but will 
        not object to recording it as the consensus of the group
Straw Poll: motion to adopt proposal as amended
<sanjiva> +1 to JeffSch .. I'll abstain this time :)
<dbooth> Straw poll: Adopt AD proposal as amended (to be not 
        required of all conformant WSDL processors)?
<sanjiva> And then we have to figure out which spec this is going 
        into .. but that's a separate question.
<Marsh>  Yes: 16, NO: 2, abstain: 4
<Marsh>  Consensus to adopt proposal
DBooth:  Suggest separate publication as note/part4 to avoid 
         critical path for LC
<sanjiva> I think this is a new part4 .. just like we have a part 
         for all the MEPs. 
<Marsh>  RESOLUTION: Adopt AD proposal as amended (optional,
         ad:mustUnderstand).
<Gudge> +1 to having a Part 4
Sanjiva: Suggests separate Features document
DaveO:   We just voted on the all the adjustments so why can't it 
         go in the core spec?
Umit:    Part4 would be in the same track for LC ?
<asir>   Suggest Part 4: Adjuncts
<sanjiva> +1 to Glen's suggestion to avoid creating new documents.
Glen:    Part 2 could be normative extensions?
Hugo:    Sounds editorial?
Sanjiva: Quick straw poll on glen's part 2 suggestion?
<jeffsch> What is the downside to a Part 4?
Amy:     Anything else that would end up in part 2?
Marsh:   operationName?
<GlenD>  No real downside but for "yet another document"
<jeffsch> (Not pushing back on features in Part 2 but asking 
         for clarification.)
<sanjiva> Jeff: The only downside I see is that we'd have to 
         create yet another doc .. but that's not a real 
         downside.
<GlenD> SOAP has an "adjuncts" doc for the RPC stuff, the 
        encoding, and the bindings + features
<sanjiva> So editorial convenience would be to put these in part2
<jeffsch> Agreed. Editors do work that life may be easier for others.
<GlenD> That seems to work well as opposed to four separate docs
Amy:    You can create new exchange patterns, so part 2 already 
        covers "extensions and extensibility" .. 
<DaveO> I'm a big -1 on a part 4,5,6,7
<GlenD> +1 to part 2 - I need to disappear for ~5 min
<asir>  Ok to part 2
<DaveO> It will be weird to constrain the http binding by the part 2.
ACTION: Editors to add the optional AD feature to Part 2 (Issue 112).


------------------------------------------------------------------
12. Issue 158: Setting HTTP headers in the HTTP binding [.1]
  - Postpone? (DaveO, Glen to champion)

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x158

<Marsh> RESOLUTION: Close 158 as subsumed by issue 112.
Hugo:  Has been wondering about other HTTP headers such as 
       content-length ..
<hugo> ACTION: Hugo to send email about AD feature setting HTTP 
       header it shouldn't set.

------------------------------------------------------------------
13. Issue 225: Non-XML type system extensibility. [.1]
  - Mark's revised proposals [.2]
  - Mark's proposals for <types> [.3]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x225
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0174.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0050.html

Marsh:  Summarises Mark's proposal 
<sanjiva> +1 to what Gudge just said .. that's my recollection too.
Gudge:  Types that contain any type description not compatible 
        with elements, then definitions component would have a 
        new property.  Sees no reason to change 'element declarations'
        property.
<sanjiva> See
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html#othe
r-types
Marsh:  Close issue with no action?
<sanjiva> Section 3.2 of the current draft has the words describing 
          how non-xml type systems will work in WSDL 2.0.
RESOLUTION: close 225 with no action

------------------------------------------------------------------
14. Issue 230: {label} vs. {message label} [.1]
  - Proposal to fix as editorial [.2]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x230
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0051.html

RESOLUTION: close 230 with action to editors to adopt Mark's proposal
ACTION: editors to adopt MarkN's resolution for issue 230

------------------------------------------------------------------
15. Issue 220: Document interface extension semantics [.1]
  - Editorial directions [.2]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x220
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0049.html

DaveO:  What does interface extension mean? mark is right - it's 
        spread across several documents. i prefer consolidation
Kevin:  Also prefers consolidation
* pauld was there an action there?
RESOLUTION: Editorial.
ACTION: Editors to incorporate issue 220, come back to WG with any
issues.

------------------------------------------------------------------
16. Issue 233: Dynamically override Fault destination? [.1]
  - Proposal to allow faults to be retargeted [.2]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x220
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0052.html

Umit:   Intention here is unclear WRT delivery of a message 
        - fault message may not be delivered to the same target node
Amy:    We cannot guarantee delivery of a fault
DBooth: We don't need to do anything here - already covered by 
        semantics of extensions ..
Amy:    Thinks we can clarify this by an informative note or part 
        2 could describe how various extensions may effect message 
        delivery including delivery of faults
RESOLUTION 233: amy's proposal accepted
ACTION: editors to adopt Amy's proposal for Issue 233

------------------------------------------------------------------
17. Issue 168: Which operation [.1]
  - DBooth revived the thread at [.2]
  - Analysis at [.3]
  - Umit's proposal [.4]
  - Paul's related question about faulst [.5]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x168
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0112.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0300.html
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0037.html
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0043.html

Postponed.

------------------------------------------------------------------
18. webMethod issues:
  - Issue 229: useOperationWebMethod proposal [.1]
  - DaveO's proposal [.2]
  - Issue 169: Syntax for webMethod - property or attribute? [.3]
  - Proposal [.4]
  - Atom WSDL binding example [.5]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x229
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0288.html
[.3] http://www.w3.org/2002/ws/desc/2/06/issues.html#x169
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0060.html
[.5] http://www.pacificspirit.com/blog/2004/07/05/atom_03_wsdl_20

Postponed.

------------------------------------------------------------------
19. Issue 189: Binding message content to URI [.1]
  - Issue details from DaveO [.2]
    - Omitting content
    - Attributes
    - QNames
  - ATOM WSDL example [.3]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x189
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0061.html
[.3] http://www.pacificspirit.com/blog/2004/07/05/atom_03_wsdl_20

Postponed.

------------------------------------------------------------------
20. Issue 130: Need async request/response HTTP binding [.1]
  - WG in favor of adding such a MEP, with some expressing a desire
    that this be as lightweight as possible.
  - Revived proposal from DaveO [.2]
  - Sanjiva's alternative [.3]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x130
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0287.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0040.html

Postponed.

------------------------------------------------------------------
21. Issue 135: WSDL Specification readability (editorial) [.1]
  - Proposed resolution from Yaron [.2]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x135
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0059.html

DBooth:  Thinks it's not worth the effort. My work predated Yaron's 
         proposal.
DaveO:   Likes Yaron's proposal after working on part 3
<sanjiva> I'm -1 for making any drastic editorial changes at this time!
DBooth:  This would translate into a lot of editorial work - what's 
         the cost (v) benefit?
DaveO:   Volunteers working on part 3
Amy:     Worries about duplication making the document ambiguous 
Yaron's proposal:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0059.html
Straw poll: adopt Yaron's proposal?
Yes: 1, No: 11, Abstain: 10
RESOLUTION: close issue 135 with no action

------------------------------------------------------------------
22. Issue 211: Omit interface message in binding? [.1]
  - Mark's proposal [.2]

[.1] http://www.w3.org/2002/ws/desc/2/06/issues.html#x211
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0047.html

<jeffsch> +1 that operations may be implicitly bound
<umit>    Me well, it forces to use the full path to get rm, so 
          you know what you are doing :-)
<jeffsch> but that all operations must be bound
<Marsh>   Amy: Clarify that every message in every operation must be 
          bound.
Marsh:    Take this back to the list since we're out of time

------------------------------------------------------------------
23. Next steps
  - Closing issues list on Parts 1, 2, 3 except to editorial issues.
  - Email votes on any outstanding items?
  - Last Call Schedule:
    - July 15th (90 min telcon):
        Editors complete editorial work for WG review.
        Disposition of any outstanding editorial issues
    - July 22nd (90 min or less telcon):
        Approval of Last Call drafts.
    - July 26th (aka May 87th) WSDL 2.0 Last Call publication.
    - July 29th (no telcon)

Marsh: we still have 4 big topics remaining, feels like we've 
       slipped a week, so 2 hours again next week

Adjourned
Received on Thursday, 8 July 2004 14:47:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:32 GMT