W3C home > Mailing lists > Public > www-ws-desc@w3.org > May 2003

Minutes, 14 May 2003 WS Decscription FTF

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Thu, 15 May 2003 03:06:20 -0700
Message-ID: <1113DDB24D4A2841951BFDF86665EE19063746C6@RED-MSG-10.redmond.corp.microsoft.com>
To: <www-ws-desc@w3.org>

Wednesday 14 May

 Glen Daniels           Macromedia
 Youenn Fablet          Canon
 Steve Graham           Global Grid Forum
 Philippe Le Hegaret    W3C
 Kevin Canyang Liu      SAP
 Jonathan Marsh         Chair (Microsoft)
 Jeff Mischkinsky       Oracle
 Jean-Jacques Moreau    Canon
 Arthur Ryman           IBM
 Jeffrey Schlimmer      Microsoft
 William Vambenepe      Hewlett-Packard
 Sanjiva Weerawarana    IBM (till 11:30)

 Bejan Parsia           U of Maryland, Semantic Web
 Martin Chapman         Oracle
 Doug Bunting           Sun
scribe: Jean-Jacques Moreau
09:00 Properties and features TF report
    - Usage scenarios: presentation of simple feature use 
      (S1 simple feature [10]). Glen will provide the example.
    - Go over the list of pros and cons: [11]
    - Glen will illustrate more on how the ability to have a 
      generic context by using properties will be useful for 
      simplifying WSDL processor and their extensions.
    - Proposal for advertising QoS features of a Web service 
      in WSDL [12].

    Issue 2: SOAPAction has been deprecated, as of SOAP 1.2 [13].
    - Jean-Jacques proposal at [14].
    - Jacek's addendum at [15].
    - Proposal from Glen at [16], fix from JJM at [17].  Undecided on
      whether to allow WSDL 1.1 syntax, PnF syntax, or both.
    - Waiting for guidelines from PnF TF.
    - Alternate (?) proposal from JJM to allow arbitrary setting of HTTP
      header fields [18]
    - Is "FnP for HTTP binding and SOAP HTTP binding" [19] a friendly
      amendment or an alternative proposal?

 [10] http://dev.w3.org/cvsweb/~checkout~//2002/ws/desc/wsdl12/wsdl12-pftf-usage-scenarios.html#S1
 [11] http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0016.html
 [12] http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0020.html
 [13] http://www.w3.org/2002/ws/desc/2/06/issues.html#x2 
 [14] http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0050.html 
 [15] http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0056.html 
 [16] http://lists.w3.org/Archives/Public/www-ws-desc/2003Apr/0010.html 
 [17] http://lists.w3.org/Archives/Public/www-ws-desc/2003Apr/0022.html 
 [18] http://lists.w3.org/Archives/Public/www-ws-desc/2003Apr/0028.html
 [19] http://lists.w3.org/Archives/Public/www-ws-desc/2003Apr/0025.html

Brief presentation by Glen, SUBTITLE: "Une petite histoire"
Glen:     Feature is a piece of semantic.  Specs define distributed 
          state machines.  Property is a piece of context used by 
          the state machines.  There is a virtual "execution context" 
          (i.e. state) which is shared by the entire SOAP processor 
          (Web Service) (called Message Exchange Context in SOAP 
          spec)  It only makes sense to specify properties whose 
          values are user controllable (according to their spec).
          Properties can contain multiple features. Properties can 
          be shared by multiple features.  Hence they are modelled 
          as "top level" components.
Marsh:    Is this introductory material in the spec?
Glen:     No yet
Marsh:    Will need to go in spec later
Glen:     Properties contrains/values are used to set up an initial 
          execution context.  Context contains the marged values for 
          properties at all active scopes (operation, binding, 
          service).  Rules for setting up execution context prior to 
          performing an operation are implicit.  At some point, some 
          API needs to be called:
            - specific: thing.setSOAPAction(...)
            - generic: thing.setProperty(p, val)
          Generic API reduces coupling between WSDL and SOAP software
          WSDL just needs to know how to setup the context, not the 
          lowest level API.
          Example: reliability
          Remove SOAPAction?
          (end of presentation; Glen moves to the whiteboard)
Glen:     Difference between:
            <prop uri="http..."><value>foo</value></prop>
[Turning to Philippe's message on pros and cons, see  http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0016.html]
Philippe: CONS
          - Features are more verbose
            (bug fixed in Philippe's message; no need to declare 
            SOAPAction feature)
Glen:     No need to declare optional features
Doug:     How to describe interaction between state machines of 
          different features?
Glen:     Not possible, in general.
JeffM:    No different from SOAP header blocks
Glen:     Syntax little bit longer.  No schema.
Marsh:    No way to say where it appears.
Glen:     Issue if set same property at different levels; lower 
          level should win.  Issue with validation, although 
          similar problem if using extensibility element: schema 
          has to be fetched as well.  Departure from WSDL 1.1 
Philippe: soapAction was an attribute.
Jeffsch:  Does SOAP have syntax for features and properties?
Glen:     No, this is what modules would do, none available so 
JJM:      Eventually, the header block is the syntax for the 
          feature and its property.
Philippe: PROS
          - Reusability of properties
Jeffsch:  We either have a QName or URI
Philippe: - Louse coupling
          - Constraint syntax allows reducing the value set 
          (instead of simply setting the value)
          (otherwise would need specific syntax for each property)
          Other advantage is finding all properties for a given 
          operation (using XPath and/or XSLT)
Glen:     Both modes have good use cases. Similar to authoring 
          style for XML Schema (attribute vs. elements)
Jeffsch:  What's the underlying issue?
Glen:     Whether people are going to be confused with alternative 
Jeffsch:  Users already know extensibility via elements; they will 
          only need to grasp the new feature/property syntax.
Marsh:    Issue mostly for spec authors.
Jeffsch:  We are spec authors (HTTP, SOAP bindings, possibly header 
Marsh:    Which parts should use features, which part should use 
          elements? Likely confusing.
JeffM:    Abstraction opens door for potential new problems?
Glen:     No different from anything else.
Marsh:    No guarantees that because abstract everyone will do it 
          in consistent manner.
JeffM:    ok
Martin:   Relationship to ws-policy, etc?
Glen:     Similar to WS-Policy, which has IP issues?
Jeffsch:  Workshop being organised, interop tests, then move to 
          standard organisation.  Few people at first, make it 
          work, then standardize.
Martin:   Pity to have separate discussion if significant overlap.
Marsh:    Very differrent approaches, here add something which 
          might not be needed.
Glen:     Would say yes if was only WSDL; but in SOAP.
Marsh:    And exactly how W3C proceeds anyway everyday.
Glen:     Technically, a lot of overlap.
Marsh:    Subset or superset?
Glen:     Policy 1) wraps semantic behind identifier; 2) does not 
          provide way to choose between 2 options
Jeffsch:  Pick one; pick one or more; choose preference.  However, 
          features revert to english at end of day.
Glen:     Maybe the difference is ...
Jeffsch:  Decision tree.
Glen:     Domain assertion specific.
Jeffsch:  Wouldn't be able to use XPath expression.
Sanjiva:  WS-ReliableMessaging uses properties, although domain 
Martin:   Dilemma: interested in policy, but not involved, which 
          one to choose?
JeffM:    Is politics, products involved, resources, customer 
          education, etc.
Jeffsch:  Group decided for features and properties, although 
          MSFT voted against and may file minority, but currently 
          watching how things progress.
Glen:     Will test for WSDL 1.2 trigger SOAP layer?
Marsh:    Yes, eg. soapAction
Glen:     Could do same for features, for example value of 
Marsh:    Yes for the ones we built into the spec.
Glen:     ... could be as well features implemented as SOAP 
          header block
Marsh:    Skeptical that could get rid of features as late as 
          CR phase
Glen:     More Last Call thing.
?:        Depends if our own work uses features and properties.
Marsh:    1) decide about soapAction (and webMethod) or 2) 
          revisit our decision?
Jeffsch:  Claim usability is the same (QNames or URIs)
JeffM:    If keep properties and features syntax, have to use if 
          for soapAction and webMethod
Marsh:    Poll: 1) QNames or 2) URIs ?
Glen:     Only value of properties if tool can do some useful 
          thing with them without understanding them.
Arthur:   How?
Glen:     If deal with multiple binding without getting into the 
          details, can set a bunch of random properties
Arthur:   How if random?
Glen:     Are understood by back end.
JeffM:    How do you communicate them to your SOAP processor.
Glen:     Per value, or bag of properties.
Arthur:   Meaningful?
JeffM:    Generic interface?
Arthur:   Could use DOM tree.
JeffM:    Could do a lot of things if some things were also 
          standardized; at end of day, specific to implementation
Glen:     And don't want to set APIs, but not huge issue.
Arthur:   Similar to WebDAV
[Youenn:  Glen: with the qname syntax, you need to know the qname before to know that it is a feature. With the container syntax, no pb.]
[Youenn:  Arthur: define somewhere that a ns is defined for properties and points to a schema.]
Marsh:    So drop specific features syntax and have annotation 
Glen:     Not annotation, but as following example:
            <soap:operation x:soapAction="URI2"/>
            <extension-ns-is-a-property ns="URI1" xmlns:x="URI1"/>
Marsh:    Worth exploring.  So straw poll 1) new syntax above or 
          2) QNames as earlier.
Sanjiva:  Still avoiding real question: link to policy and context.
          We're trying to deal with this over the phone, PFTF.
Glen:     Would like to see specs use SOAP 1.2 style, i.e. features 
          and properties.
Jeffsch:  Not all specs would use that style, but homework worth doing.
Sanjiva:  Jeffsch suggesting more concrete syntax; but real question 
          above still valid.
Marsh:    Too premature to decide now on bigger issue?
  option 1: features and property elements
  option 2: QName (element or attribute)
  option 1: 7
  option 2: 2]
Marsh:    So still interest in feature and properties.  Arthur to write 
          up proposal ´┐Ża WebDAV?
Arthur:   If WG interested.
Glen:     How define where would go?
Arthur:   Maybe using substitution group, as Gudge does.
Glen:     Little tricky.
ACTION:   Arthur to write up the alternative/WebDAV syntax for features.

11:10 Break

11:20 BindingType proposal from Kevin [30].  Updated proposal at [31].
    Sanjiva's alternative at [32].
    Awaiting updated proposal from Sanjiva.

 [30] http://lists.w3.org/Archives/Public/www-ws-desc/2002Aug/0009.html 
 [31] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0068.html 
 [32] http://lists.w3.org/Archives/Public/www-ws-desc/2002Jul/att-0117/01-bindings-2002-07-24.html 

Binding simplification proposal presented by Sanjiva.  See http://lists.w3.org/Archives/Public/www-ws-desc/2003May/att-0046/Simplifying_Bindings.ppt.

Sanjiva:  1) Drop interface from binding, since now in service.
          2) Allow inlining interface-wide binding within a port and 
             make binding optional.
Jeffsch:  Alternative: anonymous binding.
Sanjiva:  3) Define default binding.  Most likely the moral equivalent 
             of SOAP doc/lit.
          4) Dealing with operation specific SOAPActions.
             i.e. default for computing SOAPAction
          * simple case really simple
          * (others)
          (sanjiva needs to leave)
ACTION: Sanjiva: send presentation by email to start discussion

Revisited BindingType proposal (now BindingDetails) from Kevin.
Kevin:    Reusability issue still not addressed by Sanjiva's proposal.
          - Factor out binding details in separate, new construct
          - Current binding structure remains the same
            <bindingDetail name="..." 
                           target="binding/operation/message" ...>
              <!-- binding details -->
Marsh:    Changes the component model?
Jeffsch:  No, not necessarily.
JJM:      Yes, need <bindingDetail> component.
JJM:      Or maybe not, may only be serialization issue.
Marsh:    Gives more flexibility, but adds complexity.  Especially 
          in context of Sanjiva's proposal.
Glen:     Makes it hard to look at a document and see what is 
          going on.
Marsh:    Can we relate Kevin's proposal to Sanjiva's proposal?
Kevin:    Same goal.
Glen:     Ok to merge?
Kevin:    Yes, as long as keep same functionality.  Small task 
          force to modify Sanjiva's proposal.
Glen:     Only need email on main mailing list.  Introduce 
          referential integrity feature with following properties.
          Should be able to put a name att on binding component 
          which you wish to reuse. That name att (loca name?) 
          would be qualifiable in references.  Sorry, a binding 
          extension component, eg soap component, would have a 
          qname.  Would enable other extension binding component 
          to point.
Jeffsch:  Interesting scenario: Want to reuse fact that all 
          output messages will be rpc stuff.  Have wsdl:binding, 
          inside soap:binding, would have to construct dummy 
          binding to reference.  Dummy binding not pointing at 
          any interface.  Just reusing things inside.
Jeff?:    Kevin should provide example, to make sure idea of 
          dummy binding stands.
Glen:     Don't know if syntax is different.
Jeffsch:  Dummy binding, some operation, not saying what it is...
Kevin:    Would be adding new substition group, which adds 
Marsh:    Will try to merge this with Sanjiva.
[Jeffsch: Example like?
      <soap:binding useDefault="rpc" name="rpcUse"/>
  And then used like?
    <binding name="myBinding">
      <soap:binding ref="x:rpcUse" />
ACTION:   Kevin to contact sanjiva and try to merge proposals

12:30 Issues 53-55 [20]
    - Philippe's proposal for HTTP binding [21].
      Generally accepted.  Philippe will continue to polish the 
      Proposal for discussion at the FTF, after which we expect to 
      roll it into the spec.  Examples at [22]

 [20] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/issues/wsd-issues.html#x53 
 [21] http://lists.w3.org/Archives/Public/www-ws-desc/2003Mar/0068.html 
 [22] http://lists.w3.org/Archives/Public/www-ws-desc/2003Apr/0024.html

Philippe presented the proposal, and syntax examples, to the WG.
Three issues were raised:
  1) Reusing {} from XSLT (and the escaping mechanism thereof) instead
     of () (and inventing an escaping mechanism).
  2) P&F representation of the webMethod (verb).  This may need to be
     changed depending the outcome of the P&F issues.
  3) Whether to allow parts to be encoded as URI parameters when POSTing.

RESOLUTION: Adopt the proposal into the spec.  Some parts might need
            adjusting later as the rest of the spec changes.

13:00 Lunch
14:30 Begin Joint Session with WS Architecture
      Future meetings
      IBM/Toronto            Arch: July 28-30, Desc: July 30-1 August
    ? SAP/Palo Alto          Desc: Sept 22-24, Arch: Sept 24-26
    ? Fujitsu/San Francisco  Desc: Nov 3-5,    Arch: Nov 5-7

No participants objected to this plan.

14:45 (WSDesc) Single interface per service implications on
      (WSArch) "What is a web service?"

Presented the WSDL definition of Service (<service>) adopted on
Monday.  Fielded many questions from Arch, generally about the
term "Resource", and whether each enpoint itself was a resource,
and what the URI of the entire "Web Service" was.

15:30 Break
15:45 OWL Presentation and Demo on OWL, its value in the Web Service 
      space, its relation to RDF and the RDF mapping WS Desc is
      chartered to produce, and its relation to properties and
      features.  [Bijan Parsia] [1]

  [1] http://www.mindswap.org/~bparsia/talks/may2003-wsd-wg/Overview-3.html

Bijan presented an overview of the technologies, methodologies, and
applications of Semantic Web Services.  Key takeaways by the WSDL 
chair are:
  1) Domain of Semantic Web expertise much larger than previously 
     imagined, impossible to cultivate the requisite level of 
     expertise within the WSDL WG.
  2) WSDL -> RDF/RDFS/OWL/DAML-S mapping could be owned by either
     WSDL WG or by SW.  SW gets some advantage from the WS
  3) WSDL WG needs a member from the SW community to absorb WSDL-
     specific expertise - the inverse is not practical.
  4) WSDL WG needs editorial resource with expertise from the SW 
     community.  Developing this editorial resource in-house is
  5) WSDL WG would be happy to devote time to clarifying questions
     and proposals from the SW expert.  This is more likely to
     result in a quality deliverable than simple review by WG
Bijan will take this info back to the SW community as well.

17:30 End Joint Session
17:30 Adjourn

Partial IRC log: http://www.w3.org/2003/05/14-ws-desc-irc
Received on Thursday, 15 May 2003 06:06:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:29 UTC