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

Minutes: 3 August 2004 WS Description WG FTF

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Tue, 24 Aug 2004 12:16:03 -0700
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA204AAC656@RED-MSG-30.redmond.corp.microsoft.com>
To: <www-ws-desc@w3.org>

Minutes, 3 August 2004 FTF, London
Web Services Description Working Group

Present:
 David Booth            W3C
 Allen Brookes          Rogue Wave Software
 Helen Chen             Agfa-Gevaert N. V.
 Roberto Chinnici       Sun Microsystems
 Glen Daniels           Sonic Software
 Paul Downey            British Telecommunications
 Youenn Fablet          Canon
 Hugo Haas              W3C
 Jacek Kopecky          DERI
 Jonathan Marsh         Chair (Microsoft)
 Jeff Mischkinsky       Oracle
 David Orchard          BEA Systems
 Bijan Parsia           University of Maryland MIND Lab
 Arthur Ryman           IBM
 Igor Sedukhin          Computer Associates
 Asir Vedamuthu         webMethods

Observers:
 Anish Karmarkar        Oracle
 Terry Wyatt            British Telecom
 Simon Thompson         British Telecom

Regrets:
 Ugo Corda              SeeBeyond 
 Martin Gudgin          Microsoft 
 Peter Madziak          Agfa-Gevaert N. V.
 Jean-Jacques Moreau    Canon 
 Jeffrey Schlimmer      Microsoft
 Prasad Yendluri        webMethods, Inc.

Phone:
 Sanjiva Weerawarana    IBM
 Umit Yalcinalp         Oracle
 Tom Jordahl            Macromedia

Scribe: JeffM

-------------------------------------------------------
Tuesday 3 August
-------------------------------------------------------
09:00 SOAP 1.1 Binding
    - Overview from Asir (Proposal A [20], Proposal B [21]),
      discussion about the direction and implications on our 
      SOAP 1.2 binding.

[20] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0250.html
[21] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0305.html


Soap 1.1 Binding - Asir
See http://lists.w3.org/Archives/Public/www-ws-desc/2004Aug/0007.html
Asir describes the proposal
Roberto:  What about soap encoding?
Paul:     Important point is to provide transition path to soap 1.2
Anish:    Clarify stmnt in Q4: soap 11 binding is BP conformant
needs more discussion
[Proposal A:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0250.html]
Glen:     Need to chg more things based upon version
Arthur:   There are more (minor) constraints.  Requirement should be 
          that at a minimum should be possible to describe BP 1.0/1.1
          conformant services using wsdl 2.0
Glen:     Sep question is should wsdl 2.0 ALSO be able to describe 
          non WSI conformant services
Roberto:  Is version attribute an extensibility point -- so can add 
          new versions
Asir:     Didn't consider yet
Roberto:  Profiles have 2 sets of rules: WSDL description, wire 
          constraints.  Might want to have a sep soap version for the 
          wire constraints 
Glen:     This is not a new soap version
[some discussion about the nature of the URI's defined in Proposal A]
Asir prefers Proposal A, but now presents Proposal B:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0305.html
Proposal A Pros:
  Smaller SOAP 11 Binding Note
  Piggy backs on Part 3, "free maintenance"
  Easy migration from SOAP 11 to SOAP 12
  Smaller code footprint
Cons:
  Some changes to PArt 3 SOAP Binding

Proposal B Pros:
  Independent SOAP 1.1 Binding Note
Cons: 
  New binding vocabulary, yet another
  Larger code footprint
  Bigger SOAP 11 Binding ?Note
  Maintenance, how to issue errata against notes 

Chair answers we can always republish a note to incorporate errata
Arthur:    Raises issue about why this couldn't be added to Part 3 
           rather than as a separate note
seems like its partially political, and partly procedural 
Hugo:      Decouple from REC track deliverables.  To support backward 
           compatibility -- and our charter says do it as a Note
Arthur:    Proposal a is a small addition -- could we delay LC for 
           Part 3 to get this in
Roberto:   Questions whether either proposal maintains backwards 
           compatibility with BP
JMarsh:    Need to do more technical analysis before falling down 
           the rabbit hole of how to publish
DaveO:     Worthy of looking at and would like it incorporated in 
           Part 3
PaulD:     In favor of A
Asir:      Sees B as being a big implementation effort
Glen:      Not necessarily -- can be written to be efficient
Asir:      B, because it is separate, it could diverge from the 1.2
binding
Glen:      Thinks that is quite unlikely. Concern that by incorporating 
           into WSDL 2.0 spec, it will discourage migration to SOAP 1.2.
           Maybe the differences between SOAP 1.1 and SOAP 12 may not be

           quite so evident. Once we get into it, we may discover more 
           diffs
Arthur:    Agrees bigger code footprint for B.  Soap 1.1 binding is less

           disruptive and encourages people to migrate to WSDL 2.0 since

           they can decouple the migration decision for WSDL from SOAP 
           migration decision
DavidO:    Having soap 11 as a separate note, then makes it somewhat 
           harder to use soap 11 with wsdl 20
Glen:      Making it a first class part of spec does not affect ease of 
           use/integration
DavidO:    Developer should decide on soap 11 vs. 12 based upon the 
           merits of soap version and that wsdl 2.0 should be agnostic.
           With wsdl 2.0 hat on -- this will encourage migration to 
           wsdl 20 regardless of how the soap 11->12 migration goes
Hugo:      Charter is clear what we have to do -- packaging doesn't 
           affect how easy or hard it is to use
Jeffm:     Packaging discussion is irrelevant to users -- they don't
           read/implement specs - they use what the vendors ship. So 
           lets get off the politics of the implications of the 
           packaging and discuss the technical issues
[hugo:     "Binding descriptions for SOAP Version 1.1 over HTTP/1.1 
           (W3C Working Group Note), along with an implementation 
           report. Participants are encourage to provide implementations

           of this binding." http://www.w3.org/2004/02/ws-desc-charter]
JMarsh:    Yes, lets put the packaging discussion aside. If we want 
           to change we have to inform the AC so it can approve. Way 
           to do that is to produce a WD.
Arthur continues the deliverable discussion
But has been properly chastised and sits corrected :-)
JMarsh:    Important issue is whether version should be extensibility 
           or an enumeration.
Asir:      Really an enumeration, should be a string
DavidO:    Wonders if we could think of the version as in some sense 
           specifying a profile.  Combine the notion of profile and 
           version
JMarsh:    Using the profile thing makes things more complicated with 
           little benefit
Glen:      I should be able to put in an annotation which says what i 
           accept/process
DBooth:    The restriction about what i do/don't should be documented 
           in the service def (WSDL)
Glen:      It is quite likely that a vanilla soap 11 client using a 
           vanilla doc-lit service will most likely just work if the 
           service is BP conformant.  So why make it have to understand 
           the version/profile -- seems like the wrong side of the 
           trade-off
DavidO:    If i have spec that is constraining another spec, at some 
           point should have an identifier which identifies the 
           restricted set
[discussion wander off into profile conformance]
JMarsh:    Reminds group we should be focusing on deciding between 
           approach A and B
Paul:      Asks if can make 2 claims -- asir demonstrates no
Straw poll: 
  Proposal A: 8
  Proposal B: 4
  Abstains: 5
RESOLUTION: Consensus is to move forward with A as a "base"
[2 of the B's are concerned that is not "that simple" and that we may to
re-evaluate.  B preferers are ok with investigating A]

10:30 Break     ----------------------------------------

10:50 SOAP 1.1 Binding (cont.)

Back to Q2 in
http://lists.w3.org/Archives/Public/www-ws-desc/2004Aug/0007.html
[issue because soap 11 doesn't have the notion of soap module]
Hugo:    Could say that to use an extension you should use a uri to
describe 
         It.  Need to add some text to describve what we mean by using 
         modules
[doesn't look like security is a module -- from WSS spec]
DavidO:  No problem with allowing modules in soap 11 binding
Anish:   Would we provide something equivalent to notion of soap:header
         so use AD feature.
[pauld:  wonders how WS-I BSP describes ws-security modules: 
 
http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0-2004-05-12.html]
Hugo:    Notes the XMLP WG commented to OASIS WSS TC that they should
have 
         used soap 12 concepts, but the comments were ignored AFAIK
Roberto: How much of a "conceptual backport" do we really have to do
DavidO:  Doesn't really "mean" anything -- ON THE WIRE - to backport 
         notion of modules
[Anish: http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#soapmodules
-- URI to SOAP 1.2 modules]
Glen:    Purely a way to allow me use an extension in both soap 11 and 
         soap 12
DavidO:  Essentially a way to "package" up the namespaces
Glen:    Could simply use the AD feature
Igor:    Thinks we need more description.  Add the extra description in 
         6.1 
JMarsh:  Notes we need to make some changes to LC docs to accommodate
Straw poll: Allow soap module to be used in binding
  9 in favor, 0 opposed
RESOLUTION: Allow soap:module to be used in the SOAP 1.1 binding.

Q3: need to invent URIs
Asir:    Prefers use of the soap 12 naming convention
JMarsh:  Any objections?
Hugo:    Would like to have a "wsdl" somewhere in the uri
no objections
RESOLUTION: Use soap 12 naming convention.

Q5: should we allow the SOAP11 oneway msg exchange pattern 
Glen:    Suggests not using the mep attribute at all, because there 
         is nothing to which to map it in soap 11.  Question is what 
         does it buy you?
[Sanjiva: Is Glen also suggesting dropping the @mep for the soap12 
         binding or just for 1.1? if only for 1.1 I'm +1 for it; 
         I agree that soap11 doesn't have a mep concept in it.]
[just for 1.1]
Glen:    Does not want to drop for 1.2 -- wishes for a better way to 
         assoc wsdl and soap meps, but thats a different dream :-)
Glen:    When verison is 1.1 the mep attribute can be safely ignored
Sanjiva: Asks if we will keep the protocol attribute
[suggestion to use the wsdl1.1 transport attribute -- see Q3]
Glen:    Either disallowed (fault) or ignored are the 2 options
[3rd option: continue trying to figure values to use]
[Sanjiva: I suggest we disallow the use of @wsoap:mep .. that's a 
         soap12'ism and it'll be confusing to have it there. ]
Straw Poll: whether to invent uri's for meps 
  the NO's have it by a landslide
Straw Poll: fault if it appears or just ignore
  Fault: 0
  Ignore: 5
  Abstain: the rest
Consensus is ignore
[sanjiva: hey my vote was +1 for faulting ..]
[sanjiva: oh well; I lost anyway.]
RESOLUTION: Ignore @wsoap:mep.

back to Q4: what is relationship between soap 11 binding and BP 
[Sanjiva: Looking at that question - it may be useful to alllow a 
          *single* binding to describe both soap12 and soap11/bp1.0. 
          (esp. since we've dropped @style .. so we've effectively 
          cut off rpc/lit from BP/1.0 already)]
Glen:     What if somone wants to provide both soap 11 and soap 12 
          at same endpt and use the same binding
[that issue is independent: renamed to Q6]
JMarsh:   Can put a conformance claim into wsdl--describes the 
          conformance of the wsdl
[discussion of why should this WG define such a claim]
[Sanjiva: I can't hear everything but my pref would be for the 
          wsdl2 defined soap11 binding to cover soap11/bp1.0 scope and 
          not beyond. That is, we don't need to support soapenc and 
          all that stuff.]
Pauld:    We decided earlier you can make conformance claims against 
          the wsdl doc, but you could add additional constraints on 
          what is allowed on the wire
Glen:     Question is how to express the additional constraints 
          without breaking a client that actually respects those 
          constraints but doesnt "understand" the constraint URI
Anish:    Maybe we should generalize this concept
[back to the packaging discussion]
[Pauld:   Suggests packaging is uninteresting -as the note could be 
          "see part3"]
JeffM:    The argument is that the target of this "soap 1.1" binding is 
          not really soap 1.1 but the version of soap defined by the 
          ws-i BP: call it soap 1.1prime
DavidO:   Another way to think about it is that their is a "list" of 
          specs which are constraining the messages.  We could list all 
          the specs, or we could wrap them up into one uri.
Disadvantage 
          of the one uri approach is that you would have to "understand"

          the new "one" uri, even though you already understand all the 
          uri's that are being wrapped up.  Hence limits its usefulness.
          Thinks there is an implicit wildcard in the charter.
GlenD:    Thinks we should follow the charter and do a soap 1.1 binding 
          and keep profiling separate
DavidO:   Should do the profiling thing because others (wsi) will do 
          it
Pauld:    We (BT) take the wsi profile and make it work :-)
JeffM:    Maybe rather than doing the soap 1.1 binding is that we should

          do the soap 1.1 prime binding
[Roberto: +1]
Anish:    wsdl already has facilities to indicate what pauld wants to do

12:30 Lunch     ----------------------------------------

Scribe: DOrchard

13:30 SOAP 1.1 Binding (cont.)

DavidB:   BP does a refinement of soap 11.  A bp service might not 
          be compatible with soap 11, ie it is incompatible.
GlenD:    Everybody agrees bp is important.  Does soap 11 binding allow 
          non-bp profile?  If say full soap 11 and yet want to say bp, 
          then 2 decisions: is soap version(or some other name) used for

          bp or an extension/  
[GlenD:   Cheap proposal - we could use an attribute/marker on the soap 
          1.1 binding to indicate rpc/encoded.  This would entail 
          MUST-ing the rpc style...  It would obviate the need for
things
          like the WSDL 1.1 "namespace" attribute, since the NS is in
the 
          schema.  The standard rpc-style schema restrictions would
apply.
          And arrays would be indicated in the WSDL-1.1 style (deriving 
          from SOAPArray, etc).
[Roberto: They told him don't you ever come around here
          Don't wanna see your face, you better disappear
          The fire's in their eyes and their words are really clear
          So beat it, just beat it.
[GlenD:   The idea of this would be to support RPC encoded legacy
services.
          Oh sorry.  one more thing.  The schema would be understood to,
          since it's encoded, represent a structural description, but
not 
          a validatable one.  I.e. use the WSDL 1.1 type mapping, which 
          says any given element might be <foo>content</foo> or 
          <foo href="#c"/>]
Jacek:    Can't put this in the spec as "close" to normative because of 
          schema language around what "encoded" means.
Glen:     We would add a style all the way down and define a style.
Paul:     What is the implication of saying that the message part is 
          encoded?
Glen:     Not defining new schema language, it's a different 
          interpretation of schema.
Paul:     Would like to take existing services and describe in wsdl
2.0... 
          Can't take any old schema and say "is rpc" or "is encoded".
          You are doubling the # of tests.
[why?]
[GlenD:   The interpretation == the schema, rather than describing an
          infoset to be used for validation/serialization, describes an
          infoset which is used (structurally) to build a SOAP data 
          model, and *that* is what gets serialized]
Paul:     Have to put service in rpc/lit, rpc/encoded.
[some discussion about rpc.... ]
[GlenD:   This is, although interesting and potentially useful for 
          legacy apps, primarily an intellectual exercise. If it could 
          be done, that would be nice, but the potential problems may 
          indeed be too great.]
Paul:     Want to deprecate encoded.
[GlenD:   Nothing is being proposed. This is just discussion.]
Marsh:    There's 3 proposals: support 1.1 fully, support bp only soap
1.1,
          and ?
Jacek:    Propose to cut whatever bp cuts.  And that we don't have to do

          work to cut
Strawpoll question: limit wsdl 2.0 to BP 1.1 subset of soap 1.1
Glen proposes: OR soap 1.1 support at level of soap 1.2 support, ie drop
encoding, don't say anything about charsets.
[Roberto: soap 1.1 minus encoding vs. bp 1.0]
[Lots of people ask about bp 1.1 versus bp 1.0.  Do we need to talk
about which version of bp...]
[discussion about encoding..]
Roberto:  For encoding, can have either href or value.  Encoding some 
          times <element xsi:type="xsd:int">100</element>, but this is 
          illegal because type is an attribute and not allowed on 
          complex types
[lots of people disagree]
Roberto:  Using xsi:type is discourage
Strawpoll: 
  Limit to bp 1.1 subset of soap 1.1: 3
  Limit to soap 1.1 minus encoding: 11

Next question: How do we indicate bp 1.1 conformance.
First option:
  <binding version/profile/spec="soap11uri bpuri"/>
Second option:
  <binding version="11uri" wsi:profile="bpuri" bt:profile="bturi"/>
[JacekK: what is bt:profile?]
Anish:    Can't really mark wsi:profile as required, could to as
elements.
[Pauld:   A subset of the WS-I that interoperates :-)]
[Helen:   Question: in option 2, is there an assumption that bt profile
is 
          a subset of wsi?]
Second option part 2:
  <binding version="11uri">
    <wsi:profile wsdl:required="true">bpuri</wsi:profile>
  </binding>
Marsh:    Convenience of #1 is providing semantics and relationship 
          between uris.  Exact relationship is?
[relationship is union of constraints]
[dbooth:  (And presumably all constraints must be met.)]
Anish:    Wsdl 1.1 encoding attribute on binding had list of URIs (ie 
          soap encoding). Caused interop problems.
[Asir:    here is the link to SOAP 11 encoding style issue -
   http://lists.w3.org/Archives/Public/xml-dist-app/2001Oct/0330.html
          the one mentioned by anish]
[Pauld:   Points out that style is an unordered list of URIs]
[Sanjiva: Are we seriously considering binding/@version??? That's ugly 
          because that gives the sense that that's the version of the
          binding and not of the binding namespace in use!]
[Asir:    mm .. nope, we are not considering binding/@version attribute]
[sanjiva: thanks :)]
[Asir:    Sanjiva, that binding/@version is a typo]
[sanjiva: ok .. but its in the minutes repeatedly without a correction!]
DaveO:    BT can control that the clients must understand bt:profile to 
          talk to BT.
PaulD:    This can be constraint or additional information.
Glen/marsh: these 2 are very similar
Paul:     Likely to have only 1 profile in play
Davidb:   More than 1 profile
Daveo:    WS-I doesn't care about the marker from extensibility point 
          of view. The BT should care though.
GlenD:    All required extensions are effective in conjunction.
[asir:    in UK, BP is an acronym for British Petroleum]
Pauld:    It's easy to say something occurs never or once, once we 
          allow more we gotta go into combinations.
RESOLUTION: The version attribute won't indicate profiling.

Q6: single binding for single binding for soap 11 and soap 12
Asir:     Proposes wsoap:version="1.1 1.2"
[Now to question 6: should we have a single binding for 2 soap versions]
[GlenD:   Actually it's: *can* we have a single binding instance for 
          both soap 1.1 and soap 1.2]
Asir:     Bit of a problem with wsoap:protocol. wsoap ns is soap 
          version specific. Need soap ns that is version agnostic?
Glen:     Right now, asir's suggestion is to invent a value for protocol

          for alsjkdflkfjsdlgasfdlhkda;slkjfsdalk
[igors:   I think it should be
          <service>
            <endpoint binding="mySOAP11" address="abc"/>
            <endpoint binding="mySOAP12" address="abc"/>
          </service>]
Marsh:    We define 1 value for protocol for soap 1.2, potentially
another
          for soap 1.1.  This is syntactic shortcut for 2 bindings.
Strawpoll: consider supporting both soap versions in a single binding.
Hugo:     Very special case. Can have other protocols.
Asir:     If this is true, do we need to support soap 1.1 soap 1.1 
          binding note?
Paul:     Need to support 1.1 only.
Roberto:  Creates more problems than it solves. what does ws-i profile 
          conformance inside the binding?
Marsh:    Anybody a champion of this?
no.. [moving on to better things.]

Marsh:    We will describe the changes to part 3 as lc comments, and
also 
          do changes to soap 1.1 note.  We agreed to do a soap:version
          attribute in part 3.
Asir:     About 3 weeks until note is released...

15:30 Break     ----------------------------------------

15:50 RDF Mapping
    - Overview from Bijan, Q&A, discussion about next
      steps.

http://lists.w3.org/Archives/Public/www-ws-desc/2004Aug/att-0018/2004-Ju
ly.ppt
http://lists.w3.org/Archives/Public/www-ws-desc/2004Aug/att-0019/RDF.pdf


Bjian:    Want to enchance wsdl with semantics.
Davidb:   Also want to integrate wsdl with other kr systems
Bjian:    swsl will be the merge of wsmo and owl-s and be usable into 
          wsdl.
[Bijan goes through slides.]

[Pauld:   Notes the collective noun for OWLs is 'stare' or 'parliament']
DavidB:   The infoset is an abstraction that represents meaning of 
          physical representation. WSDL has a component model that
          represents meaning of infoset.  Model the component in rdf 
          choice is a direct transliteration of component model into 
          rdf. 
Bijan:    Owl doesn't use schema types because they use URIs and there 
          aren't URIs for the schema types.
Asir:     Schema/Jeremy Caroll from semantic web are looking at the 
          SCUDs for doing URIs for user defined types.

-----------------------------------------------
ISSUE 252 - syntax of media type annotation

Umit:     Schema api as w3c note, no support for additional attributes, 
          but there is support for annotations.
Glen:     Attributes are defined within the appinfo 
Asir:     There is getAnnotation string. Returns text representation of
          string. This means ?
[asir: link is at
http://www.w3.org/Submission/2004/SUBM-xmlschema-api-20040309/xml-schema
-api.html#Interface-XSAnnotation]
[GlenD:   We don't know that this API is even adequate for <appInfo>!!!]
[Asir:    Look at annotationString]
[Roberto: ATTRIBUTES ARE ANNOTATIONS]
[GlenD:   Schema annotations CONTAINS attribute extensions.  They aren't

          different things. They aren't different things.  They aren't 
          different things.  They aren't different things.]
[asir:    +1. +1. +1.]
[Roberto: There are NO "schema extensions" whatsoever]
[asir:    +1]
[can somebody sumarize this?]
Glen:     Working group preference is attributes instead of appinfo.
Marsh:    Close issue 252 by adopting an attribute based syntax, put in 
          an ednote that an attribute annotations might not be exposed 
          by schema processors.
RESOLUTION: Close issue 252 by adopting attribute based syntax, add
ednote
          that attribute annotations might not be exposed by existing
          schema processors.
[sanjiva: I'm going to drop off ... if there's a discussion of
publishing 
          a WD of the RDF mapping, I'd like to request some time to have

          the work reviewed by interested parties in IBM. Several groups
          have expressed interest in it and so we need some time to 
          review and develop our positions. Thanks for considering
that!]
Glen:     Send to soap builders
ACTION:   Glen to send a message about the mediaType annotation
          (attribute/appInfo) to soapbuilders.
Asir:     Few implementations of 7 schema apis support annotations.
Marsh:    Rolling in these issues should get to last call for media
types
          document.

17:00 Adjourn
Received on Tuesday, 24 August 2004 19:16:37 GMT

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