Minutes: 22 Jan 2003 WS Description FTF

-------------------------------------------------------
Wednesday 22 January
-------------------------------------------------------
Present:
 Erik Ackerman          Lexmark
 David Booth            W3C
 Allen Brookes          Rogue Wave Software
 Roberto Chinnici       Sun Microsystems
 Youenn Fablet          Canon
 Martin Gudgin          Microsoft
 Tom Jordahl            Macromedia
 Philippe Le Hégaret    W3C
 Steve Lind             AT&T
 Kevin Canyang Liu      SAP
 Michael Mahan          Nokia
 Jonathan Marsh         Chair (Microsoft)
 Dale Moberg            Cyclone Commerce
 Don Mullen             Tibco
 Arthur Ryman           IBM
 Jeffrey Schlimmer      Microsoft
 Igor Sedukhin          Computer Associates
 William Vambenepe      Hewlett-Packard
 Steven White           SeeBeyond
 Umit Yalcinalp         Oracle
 Prasad Yendluri        webMethods, Inc.

Observers:
 Martin Duerst          I18N
 David Orchard          BEA
 
Phone:
 Amelia Lewis           TIBCO

[Yoenn scribes]

-------------------------------------------------------
09:00 Approve publication of WDs.

Jonathan: Objection to publishing part 1 & 2?
(no)

-------------------------------------------------------
09:05 Requirements Document Last Call comments
    - Request to address attachments [19]
      (IBM\John Ibbotson and IBM\James Snell)
    - Comments re: various requirements [20]
      (BEA\David Orchard)
    - A thorough accessibility review [21]
      (chair of the W3C/WAI Protocols and Formats WG [22])

      Goal of this session is to dispatch some of the easier ones, while
      identifying dependencies among the others (e.g. completion of
      Requirements for the SOAP Attachments Feature by the XMLP WG).

 [19] http://lists.w3.org/Archives/Public/www-ws-desc/2002Dec/0081.html
 [20] http://lists.w3.org/Archives/Public/public-ws-desc-comments/2003Jan/0000.html
 [21] http://lists.w3.org/Archives/Public/public-ws-desc-comments/2002Dec/0002.html
 [22] http://www.w3.org/WAI/PF/

Jonathan: 3 sets of req comments.
          1 = attachment, but wait for xmlp wg.
          2 = DaveO's comments
          3 = extensibility reqs
          We'll take up DaveO's [20] while we have him.

DaveO:    First paragraph about style of reqs.
(discussion about DaveO's reqs)
DaveO:    It seems reqs written toward design.  Some kind of 
          generalization might be made.  Some examples in my mail.
          Example = R118.
Jonathan: Terminology seems too specific.
DaveO:    Yes, written toward design.  R118 is for reuse of components.
          Rephrase as "should allow the reuse of a group of interfaces"
Gudge:    We designed a way to reuse interfaces without the serviceType 
          thing, so you're right.
DaveO:    R058 is the same as R118.
Jonathan: No pb rephrasing them.

DaveO:    I have some other examples.
Jonathan: Maybe we should ask the editors to point out the ones to 
          rephrase.
Jonathan: DaveO's comment = not only R058 and R118 have the same problem
ACTION: Jeffrey to rephrase requirements R118, R058, and point out reqs
        that seem to specify a design and propose rewording.

Topic: Comment #1
DaveO:    Concrete sugestion. The description language SHOULD provide for 
          validation of WSD documents that are entirely abstract and MUST 
          not contain non-abstract information and provide for validation 
          of WSD documents that are entirely concrete and MUST not 
          contain abstract information.  Design to separate concrete and 
          abstract info.  Hard to ensure that wsdl files are abstract or 
          not.
Gudge:    If you refer to the abstract components, no more pb.
DaveO:    But if you include a wsdl file, you will also import concrete 
          components.
Gudge:    Why not defining a special "only abstract" import?
DaveO:    We can write special wsdl abstract files for choreography.
Gudge:    Right, but if someone has written what you want and added 
          concrete things you should reuse this work.  You do not need 
          "only abstract" wsdl files to do what you want...  I can 
          write a schema only allowing abstract components, it is 
          technincally doable.
Jonathan: There was a suggestion on the wg to alwyas split the wsdl file 
          in two (abstract & concrete) files.
Gudge:    Tools can always ignore/filter the concrete things...
Umit:     It seems like a toolability issue.
DaveO:    It is also about reusability of wsdl in other languages like 
          choreography.
Gudge:    A porttype is complete by itself, it does not need binding to 
          complete its semantic.  Our design solves your issue.
DaveO:    I feel some pushback...
Tomj:     You can always validate the wsdl.
DaveO:    You can always enforce some rule with a sub-schema.
(more discussion on validation of abstract wsdl files...)
Gudge:    You can have a wsdl files that only contain services elements 
          or portType elements but I won't help solving your pb.
DaveO:    Taking a lookout of wsdl then extract of a subset.
Gudge:    Why can't you write a choreography spec that says we only use 
          the abstract components (portTypes and messages)? The pb is that 
          the concrete binding in the wsdl file will be superceded by 
          concrete info from the choreography file.
DaveO:    Can you write a schema that only allows abstract components?
Gudge:    Yes it is trivial.
DaveO:    You can have a full schema and then two separate (abstract & 
          concrete) schemas as profiles.
Jonathan: We can do that  but not sure of the value.
TomJ:     Can we move on ?
DaveO:    We are not that in a hurry.  I can do the separation, I have 
          done it but it will help people to have this in the spec.
(discussion about uddi)
Arthur:   You do not include a wsdl file but a link to it then you 
          register...
Gudge:    With the import mechanism, no way to insure there is no 
          concrete info even with a schema.
(discussion about reqs that we decide not to do)
Jeffsch:  These are still in the doc.
ACTION: Jeffsch to document as a non-requirement.

Topic: Comment #2

DaveO:    2 is about use cases. I try to track what the wsd wg does and 
          it is difficult to know why some decisions have been made.
          Some use cases could help. I 'd like use cases to be written.
Jonathan: No use cases editor around the table. We cannot promise 
          anything.  Lots of decisions are made to solve issues.
          Rationale and closing of issues help understanding this.
DaveO:    When closing an issue, an illustration would help.

Topic: Comment #3 (no reqs on description of XML based Message content 
          constraints)
          
DaveO:    Nowhere it is said that you can have a schema that will 
          validate the message contents.
TomJ:     Pb with the data encoding.
JeffSch:  And also other schema languages.
DaveO:    We can rephrase with syntactic schema languages.
ACTION:   JeffSch to add this requirement (suitably worded).

Topic: Comment #4 (The description language definitions MUST describe 
          constraints upon service locations for http: URIs, and SHOULD 
          describe constraints for URI schemes in addition to http:.)  

JeffSch:  For the non soap-http binding, having url scheme (?)  For 
          example a soap-smtp binding?
DaveO:    Mix parameters in the url as well as in the soap binding.
          We can generalize the http binding url replacement.  We 
          should allow people to describe other bindings than http 
          at least in the url replacement.
Jonathan: Objection ?
JeffSch:  A little bit confused with the first sentence.
(ok adding this req)
ACTION: jeff to add this req

Topic: Comment #5 (The description language message definitions SHOULD 
          describe constraints on non-XML based message content)

DaveO:    You reach this the mime binding. Number 5 is met
TomJ:     Constraints of non XML data ?
DaveO:    Yes with the mime type attribute.
JeffSch:  The req is to produce a normative binding to non XML message?
DaveO:    We are not talking of XML.  A web service accepting non XML 
          data should be able to described, at least with the mime type.
Jonathan: On the board, here is an example of a mime:type.  Someone can 
          do it but we are not doing to create normatively such a 
          language.
DaveO:    Is it normative in WSDL1.1 ?
Gudge:    Wsdl1.1 is not a standard
DaveO:    Then I like my req
Gudge:    A binding and a type system are very different.  Do you want 
          a mime binding or a mime type system ?
TomJ:     He will take a mime binding.
DaveO:    A mime type system also.
(discussion on rephrasing the req)
DaveO:    I like this <mime:type> thing.
Gudge:    It is a mime type system.
Roberto:  We should solve this at least at the binding level.
DaveO:    We should also have a way to validate messages.
JeffSch:  Abstractly you can define messages with different media 
          entities. On the wire, you are not sure it will be serialized 
          as a mime-multipart message.  E.g. it can be serialized as 
          base64.
Gudge:    At the abstract layer, you don't know how it will be 
          serialized.  At the abstract level, what do you really want ?
DaveO:    I am not sure....
Gudge:    If you care about the serialization, we should have some 
          kind of mime type binding.
ACTION:   JeffSch to reword req 5 and DaveO to review it


Topic: Comment #6 (Remove R110 - seems way too specific)

TomJ:     Should we wait for William to decide ?
ACTION: Jonathan to add this on our cut list and wait for william.

TOpic: Comment #7 (The description language MUST support message parts 
          that are in the address and the body.  The WSDl 1.1 
          http:urlReplacement element says that ALL the message parts 
          are in the URL. But imagine the use case of POSTing a purchase 
          order.  The purchase order ID might be in the URI, whilst the 
          POST body contains another message part.
          
Gudge:    No technical reason for the soap-http and http bindings not 
          to do that.
Arthur:   Uri usage today does not conform to the arch view.
DaveO:    We should allow the modeling to choose between adding the 
          purchase_id in the url or in the message body.  The approach 
          is to support soap and then add the url:replacement thing.
          I think that these things are more coupled.
JeffSch:  It seems interesting.
DaveO:    This is a web arch suggestion.
Arthur:   What about multi-hop messages.
Jonathan: Add this req as a should ?
DaveO:    If you do not accept this req, there might be some push-back 
          from the tag...  Why not adding a generic req to allow map 
          parts into the url ?
Arthur:   It is the case in the http binding.
DaveO:    But not for the soap binding.

ACTION: jeff to add this reworded req

Topic: Comment #8 (The description language MUST support optional 
          message parts in the address.  I don't see a way of using 
          http:urlReplacement and having some parts being optional. 

DaveO:    Need to add optional parts.
Arthur:   Parts are not optional at all.
JeffSch:  We had an issue about url-replacement. We might want to 
          reopen this issue.
DaveO:    At the moment, every part must be encoded in the url if 
          using the url replacement.
JeffSch:  Tag priority for this req ?
DaveO:    Good to have but not essential.

Topic: Comment #9. (The description language SHOULD provide for 
          description of optional message parts)

JeffSch:  Vigorous push back if needed to reinventing xml schemas 
          things. Discussion in this wg and several proposals.
DaveO:    If using xml-schema for message parts, how will you 
          relate to url replacement ?
JeffSch:  It is not any harder.
(discussion on this topic... (one solution is xpath))
Reword: Description loangauge must or should provide for description 
          of optional content.
TomJ:     No must because we may want to keep the status quo.
Umit:     And we close the door for ibm's proposal.

Topic: Comment #10 (The description language SHOULD provide a 
          construct for references to identifiable elements.
Gudge:    Is it R120?
Arthur:   Is it R085?
Gudge:    Even in WSDL1.1 a message can include a wsu:portReference....
DaveO:    Yes but we should have this in the spec, in the wsdl ns
Gudge:    The wsu thing already exists.  Is it that this element is 
          not standardized?
DaveO:    There should be one construct defined by this wg.
Roberto:  R120 will do 95% of the work so why add this new req?
DaveO:    Suggestion: The description language SHOULD provide a 
          construct for references to identifiable elements.
JeffSch:  Change "desc language" to : "the wg" should provide a c...

ACTION:   Jeffsch to propose wording for requirement related to a 
          portReference construct.


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

----[Begin Joint Session with Architecture Group]----
-------------------------------------------------------
10:50 Status report for dependent documents (Usage Scenarios,
      Glossary, etc.)

Jonathan: Editor's copy are public and wd to be published. Usage 
          scenarios: no editors here and they are on the floor.
Hugo:     Some comments about the doc (arch usage scenario).  Need 
          to go through and decide what to do.  No update since 
          the publication.
Jonathan: Priority is part 1 & 2 but usage scenario is in our charter.
MikeC:    A unique arch&ws usage scenario ?
Jonathan: Back out if coordination makes things harder or we can make 
          the coordination work.
MikeC:    We should have a joint document. It is more on the arch side 
          and the ws wg should just point to this doc
Jonathan: If any update by arch wg, let us know.
MikeC:    Revigorate a joint task force?
???:      Do the use cases drive things like the 7meps things?
Jonathan: Yes but these use cases are not formally written.
DaveO:    Maybe the wsdesc wg should review and update the doc the 
          arch group made.
Jonathan: Maybe time to reappoint editors ?
DaveO:    Maybe somebody should drive us for the reviewing process. Use 
          cases and reqs are coupled.
[Chair's summary: Will reappoint Useage Scenarios TF members.]
          
Glossary status

Hugo:     No new draft.  Some conflicting definitions, missing ones also
          We will publish it soon.
MikeC:    Capitalization of wEb ServIce ?
Jonathan: Yes, done

-------------------------------------------------------
11:00 Message Exchange Patterns - current state of WSDL.

Jonathan: A word about message exchange pattern.  There are three problems
          First= soap has the mep mech, wsdl has input output things, how 
          to relate.  Second= outbound operations. Claim that they are not 
          interoperable. Third= Documenting Inbound operations better. We 
          have a plan.  Don Mullen has an abstract mep framework.  We 
          think the ws-arch should own a template for mep.
???:      What about features ?
Jonathan: Ongoing discussion.
Hugo:     New features like Ws-security arise.
Jonathan: Cannot use the soap-uri for the wsdl request-response.  We will 
          have new uris. in, in-out, and so on. 123 and 456 are mirrored 
          ops. Last one is with one out and in msgs from multiple nodes.
DaveH:    Document for guidance?
Jonathan: Yes, and we use the feedback from our 7 meps building to refine 
          the abstract mep template and guidance doc.
(explanations on meps)


-------------------------------------------------------
11:20 I18N Web Services Task Force introduction and overview
        (Martin Duerst).  First WD of Web Services I18N Usage
        Scenarios [23].

 [23] http://www.w3.org/TR/2002/WD-ws-i18n-scenarios-20021220.


Topic: internationalization of web services (Martin Duerst)

Martin:   Glad to be here
[<dbooth> (The projector fails to work, so Martin starts without it.)]
Martin:   (see http://www.w3.org/2003/Talks/0122-duerst-wsdl/)
          Talk about the issues we tackle. Started last December. Work 
          item is usage scenarios. Should be completed before the summer 
          vacation. At that time we should know the remaining work.  Make 
          sure that WS works worldwide.  Few examples between ws and 
          internationalization.  For instance encoded text. Certain web 
          services may have int. aspects that you might want to describe.
          There are also interesting applications of ws to int.  The 
          80-20 rule is not that valid for int. day format web service.
          Interesting efficiency issues (caching...).  Usage scenarios 
          doc: Data encoding, language negotiation, language negotiation 
          for soap faults.  Examples of how you might want to transmit 
          your data.  Presentation rules might be local.  Best 
          practice/guidelines to build web services wrt int. aspects.
          Content like currency.  User interfaces issues. Consistency 
          across platform issue.  Look at extensibiliy mechanims. 
          Another issue is architectural complexity.  Independency of 
          components is good for us, less work.  Sanjiva sent a 
          proposal which seems to be a kind of abstraction that we might
          need. Happy to discuss with you.  Please advertize our work 
          to interested internationalization people in your company.
          We are looking to close infrastructure issues.
MarkJones: Int. aspect with the concrete attachment feature work ?
???:      Example = attachment with a cartoon in japanese and one in 
          english
Martin:   Language negociation is already present in http.  We should
          check with dime.
MarkJones: The binding could have a kind of a DNS resolver for parts (?)
Daniel:   Concerning ws-arch, we should have a req that allows int. 
          plus section 2.2.10.
Martin:   Maybe some reqs on extensibiliy, composibility.
Daniel:   The points you make can generally be directly mapped to the 
          languages.  Most of the issues can be addressed within the 
          ws-desc wg.
Hugo:     Language negotiation can be done at different levels.  Have 
          you discussed which level would be better?
Martin:   If you have int. at different levels, you get conflicts.
          Difficult to see what will be the core spec (you can have 
          soap or one other thing).  If there is one place where you 
          have only one place, it would be easy.  We have not found 
          this place yet
Jonathan: Thank you martin

-------------------------------------------------------

Mikec:    Time for one more issue ?  Talks with oasis security guys 
          to come up with a wsdl desc of what they are making.
Jonathan: No real comment from the ws-desc for the ws-arch to send 
          comments to oasis guys.
DaveH:    Boundary lines between wsdl and security/policy/ontologies?
          what description means ?
Jonathan: Will say that Wsdesc wg would be interested to get feedback 
          from people that write wsdl extensions.

-------------------------------------------------------

11:50 Future FTF meetings
      - Boston: March 2-3 (Desc), March 5-6 (Arch)
      - Rennes: May 12-16 (propose Desc goes first))
Proposal accepted
      - Toronto: July 28-August 1 (propose Arch goes first)
Proposal accepted
        - West Coast?: mid-September (propose Sydney :-})
Consider West Coast in Sept, Sydney in Nov to combine with AC meeting in Japan.

----[End Joint Session with Architecture Group]----
12:00 Adjourn
---------------------------------------------------------------------

raw IRC log: http://www.w3.org/2003/01/22-ws-desc-irc

Received on Friday, 24 January 2003 14:44:13 UTC