Minutes, 14 Sept 2004 WS Desc FTF

Web Services Description F2F
Tuesday 14 Sep 2004
See also: IRC log [http://www.w3.org/2004/09/14-ws-desc-irc]

 David Booth            W3C
 Helen Chen             Agfa-Gevaert N. V.
 Roberto Chinnici       Sun Microsystems
 Glen Daniels           Sonic Software
 Paul Downey            British Telecommunications
 Hugo Haas              W3C
 Hao He                 Thomsona 
 Tom Jordahl            Macromedia
 Anish Karmarkar        Oracle
 Kevin Canyang Liu      SAP
 Jonathan Marsh         Chair (Microsoft)
 David Orchard          BEA Systems
 Bijan Parsia           University of Maryland MIND Lab
 Arthur Ryman           IBM
 Sanjiva Weerawarana    IBM

 Allen Brookes          Rogue Wave Software
 Youenn Fablet          Canon
 Jean-Jacques Moreau    Canon

 Amelia Lewis           TIBCO
 Asir Vedamuthu         webMethods

Logistics [1].

 [1] http://www.w3.org/2002/ws/desc/4/04-09-f2f.htm

Tuesday 14 September
09:00 Introductions and logistics
    - Assignment of scribes
      Roberto Chinnici, Sanjiva Weerawarana, Kevin Canyang Liu, 
      Tom Jordahl, Prasad Yendluri, Paul Downey, Hugo Haas, 
      David Booth

Scribes: Roberto, David, Kevin, Sanjiva, Paul, Tom

<Roberto> Scribe: Roberto 

    - Agenda bashing

Agenda bashing ongoing. 
Discussion on schedule. 
Work on last call issues until November. 
Then revisit the issues for which we got minority opinions. 
Then go to CR. 

09:05 Spec status overview: Media Type Description Note [2]
    - Finalize plan to issue as Last Call


Anish:    One issue was not incorporated, namely the q parameter.
          That's issue 245 
Jonathan: There's also a thread on 252 started by Umit.
RESOLUTION: consensus not to reopen 252 based on Umit's mail.

Jonathan: New issue:
Anish:    We say what @contentType means, but that does not provide 
          much value to applications.  Applications are free to ignore 
          it.  Tools cannot use the expected media type value and 
          generate special code.  Proposal is to remove the second 
          statement "the annotation should be considered only as a hint"

RESOLUTION: Consensus to remove sentence "the annotation should be
            considered only as a hint."

Jonathan: New issue: optionality of contentType attribute
Glen:     Issue says "if there is optionality in the description, we 
          should mandate that at runtime the content type is specified" 
Sanjiva:  It's fine as it is, the spec says that the two values should 
          be consistent.
Anish:    Optionality wasn't really discussed by this group until now. 
Tom:      The two attributes are linked, so we should list the rules.
Sanjiva:  @contentType wins, it tells you what the data is.  The spec 
          says that, the value of @contentType must be in the range 
          listed in the description.
Anish:    Analogy between expectedMediaType and HTTP Accept header.
Hao:      Service providers and consumers have different capabilities; 
          do we address that? 
Sanjiva:  We don't.
Tom:      The specification should address these three cases. 
Glen:     Lack of media type (or use of a wildcard) in the schema says 
          that there needs to be some other way of figuring out what 
          the actual data type is.
Jonathan: Do we need to require that implementations signal the same 
Tom:      Proposes to require contentType when expectedMediaType has 
          a wildcard.
Jonathan: This would force a messaging stack to reject all descriptions 
          that use expectedMediaType if it doesn't support contentType.
          Concern is that @expectedMediaType is very useful in many 
          contexts, so we shouldn't tie it to Web services.  Example: 
          XML Query.
<anish>   How about saying that if the expectedMediaType contains a 
          wild card or a list then the instance document SHOULD contain 
          some way for the receiver to figure out the media type of 
          the binary data. contentType attribute being one such 
Kevin:    The schema author could make @contentType required.
<dbooth>  Proposal on the table: "When expectedMediaType is used and has

          a wild card or list, you SHOULD write your message schema to 
          require a contentType." 
RESOLUTION: Consensus on adding "When expectedMediaType is used and has 
          a wild card or list, you SHOULD write your message schema to 
          require a contentType."

DBooth:   Who should register the media types? 
Jonathan: The WG, but no specific person.
<dbooth>  Info on how to register the media type:
Jonathan: Call for volunteers to manage the registration of our media 
Arthur:   Which extension should we use? .wsdl? .wsdl20? 
[.wsdl seemed to get consensus]
DBooth volunteers.
<anish>   html media type rfc -- http://www.ietf.org/rfc/rfc2854.txt 
<anish>   xop media-type --
<sanjiva> +1 for .wsd and .wsdl because our WG is called WS-D too :(

Jonathan: No other media type issues.  Do the edits tonight, then have 
          everybody review the document tomorrow and discuss any new 
          issues on Thursday.

10:40 Break     ----------------------------------------

11:00 Spec status overview: Primer [3]
    - Finalize plan to issue as 1st Working Draft


DBooth going over the primer 
Sanjiva:   Primer shouldn't use "WSD" 
[Proposal to use "DESCRIPTION" instead.]
RESOLUTION: DBooth to change "WSD" to "WSDL Document" throughout 

DBooth:    Sections up to 3.1 should be ready to go.
[discussion on "WSD" and its use in the architecture document.]
Arthur:    The primer should be completely self-contained.
Roberto:   Web services architecture document is hard to understand 
           without having some understanding of WSDL.
DBooth:    Disagrees, wsarch document is quite readable.
Anish:     Remove the architecture document reference and just have 
           the glossary.
Sanjiva:   Already section 1.4.5 of the wsarch document uses complex 
           terms we don't use in our spec. XML Schema primer starts from

           a simple example and grows it, it doesn't start with a 
DBooth:    It's important to put WSDL in context. Our intent for the 
           WSDL primer is to do as the schema one does.
Kevin:     Instead of listing the wsarch document as prerequisite for 
           the whole primer, we could list it in the section that 
           contains the diagram.
DaveO:     The interactions described in the diagram must be understood 
           to understand the place that WSDL occupies in the system. 
           The primer should not re-create a description of the 
Arthur:    A primer is for a different kind of audience, so you want 
           "progressive disclosure".
<dorchard> The first paragraph of primer introduction says "The text 
           assumes that you have a basic understanding of XML 1.0 and 
<dorchard> schema primer 
DBooth:    Prerequisites are only for information they should already 
           know before they can start reading this document.
Glen:      Strawpoll 
DBooth:    Proposal to have more specific references for the concepts 
           you need to know. 
<dorchard> "RTFA" :-) 
RESOLUTION: Accepted the proposal from DBooth to have more specific 
           References for the concepts you need to know.

PaulD:     Primer should be an introduction to the WSDL spec itself, 
           not to the whole industry.
Jonathan:  Are the editors getting sufficiently clear directions? 
Dbooth:    Would lie down on the road about being inconsistent with 
           the architecture document.
<kliu>     +1 to Dbooth 
Sanjiva:   In the spec we use "web service", not "provider agent" 
DaveO:     Isn't that because the architecture document has a wider
DBooth:    The primer must provide a wider context than what the spec
Roberto:   Proposal #1: CLIENT <-- WSDL --> WEB SERVICE 
Dbooth:    We could have Client (Requester Agent), etc 
Tom:       Text can make references to requester agents and provider
           and point to the note. 
  (1) use simplest terminology,
  (2) keep it consistent with wsarch document 

(1) is client / WSDL document / web service 
(2) is status quo 

(2) means be as consistent as possible with the wsarch terminology 

<youenn> +1 for 1 
<Allen> +1 for 1 for me too
for (1): 6 
for (2): 7 

Sanjiva:  Will lie down on the road on this.
RESOLUTION: Diagram revised to add "client" and "web service" 
          in parentheses 
Tom:      Objects to the use of requester agent and provider agent 
Jonathan: Formal vote on the same question of the strawpoll 

 1: IBM, Sun, Macromedia, Canon, Roguewave
 2: BEA, Sonic, Agfa, W3C, SAP, Thomson, Oracle
 Abstain: British Telecom, UMD

Results: 1 - 5, 2 - 7 

Option 2 wins (i.e., be consistent with the WS Arch document, which uses
"Requester Agent" and "Provider Agent") 

12:15 Lunch     ----------------------------------------

<dbooth> Scribe: DBooth 

13:15 Primer (cont.)

Roberto:  Re: Diagram 2-1, please change "Web" to "Network". 
DBooth:   Ok. 
RESOLUTION: Change "Web" to "Network" in diagram 2-1.

GlenD:    Too much stuff up front before the first example. Want to 
          give a "hello world" example and then build on it. 
DBooth:   I agree. We need to reduce the Section 2 stuff a bit. 
JMarsh:   For example, section 3.3 has an explanation of all the MEPs. 
          Does it need them all? 
DBooth:   No. I haven't reworked that part yet. 
JMarsh:   Let's focus on up through section 5 for the first WD, and 
          leave the Advanced Topics for the moment. 
Arthur:   Primer should cover simple case and things that people often 
          get wrong. Implementers often get inline schemas wrong. 
Sanjiva:  That doesn't belong in the Primer if it's an obscure case. 
JMarsh:   Maybe we should put an example of schemaLocation in the spec. 
DBooth:   Which Advanced Topics should move to the main body? 
Bijan:    Extensibility should move. 
JMarsh:   Import also. 
PaulD:    Maybe we should have another document that lists examples 
          with their rationales. 
JMarsh:   Shouldn't our test suite catch that? 
Sanjiva:  If someone wants to do the work, fine, but let's not add it 
          as a WG deliverable. 
DBooth:   How would this be different from the test suite? 
PaulD:    Different audience. Test suite would be for implementers; I'm 
          talking about examples for WSD authors. 
DBooth:   Sounds like a prime area for training companies, books, etc. 
JMarsh:   Test suite should be linked from our status section. 
GlenD:    Take out the syntax summary. 
DBooth:   Need to merge section 2 into section 1, because it really is 
          intro material.

14:00 Reusable Types for ContentType?
[New issue raised by Kevin.]

Kevin:    Should we define reusable types for contentType? 
Anish:    Two complex types, both are elements with contentType
JMarsh:   Complex type would define an element with a contentType 
          attribute. Extend it by annotating the value of the attribute.

          Instead of defining these types, you could have an import
GlenD:    This would be both an authoring convenience and tool help. 
Roberta:  If the expectedMediaType then you SHOULD set contentType, but 
          in this case you're specifying contentType first. 
GlenD:    Optional would be useful for authoring convenience. 
Sanjiva:  How about defining type for all MIME types? 
DBooth:   I'm against authoring convenience. ;) I don't think the
          is worth the cost. 
JMarsh:   We could add these to our existing schema, to be available for

RESOLUTION: Add two complex types to our XML MIME schema, one derived 
            from base64 and one from hexbinary. 

[Discussion of whether to call the namespace prefix xmlmime: or mimexml:
, because prefixes starting with "xml" are reserved.  Preference is for

Type names will be base64Binary and hexBinary. 

14:30 Spec status overview: SOAP 1.1 binding
    - SOAP 11 Binding, first draft [4]
    - Modified Part 3 (aka, added soap version) [5]
    - Modified XML Schema for SOAP in WSDL 2.0 [6]
    - Collect issues
    - Finalize plan to review


Nothing to say without Asir - skipped.

14:35 Spec status overview: RDF Mapping
    - Status update?  First peek?

Postponed till Thursday.

14:40 Last Call issues [7]
    - (In issues list order, with Asir's last if possible)

 [7] http://www.w3.org/2002/ws/desc/4/lc-issues/

Last Call Issues
<tomj> Issue: http://www.w3.org/2002/ws/desc/4/lc-issues/#LC5d 

--- Issue LC5d --- 

RESOLVED: Accept DBooth's proposed change in
ACTION:  Editors to implement resolution to LC5d at

--- Issue LC5f --- 

(Skipped pending Roberto's action item on it) 

--- Issue LC5g --- 

Proposal to delete the word "agree". 


JMarsh:   What if the processor conforms to the WSDL part but not to 
          an extension? 
TomJ:     A conformant processor MUST fail if it doesn't abide by the 
          semantics of a required extension. I have 15 extensions in my 
          WSD, and 5 are marked required. I MUST either conform to 
          those extensions or fault. 
GlenD:    A conformant WSDL processor can legitimately AGREE to abide by

          the mandatory extension even if it doesn't ACTUALLY abide by 
          it, because it's the extension plug-in's fault -- not the 
          WSDL processor's fault. 
<Jonathan> "a conformant WSDL processor MUST immediately cease
          (fault) if it doesn't agree to fully abide ...." 

RESOLVED: Accept the reviewer's proposal: "a conformant WSDL processor
MUST immediately cease processing (fault) if it doesn't agree to fully
abide ...." 
ACTION: Editors to implement resolution for LC5g as proposed.

--- Issue LC5h --- 

RESOLUTION: reclassify as Editorial. 

--- Issue LC5i --- 

JMarsh:  This says "MUST" in a Note section. 
TomJ:    The reviewer is right that this Note is about the provider 
         agent, whereas the section is about the requester agent. 
Bijan:   There are two kinds of dealing with this optionality. One is 
         that the provider agent can't send a message using the feature 
         until it gets a signal from the requester agent. The other is 
         that the provider agent could send it in an ignorable way. 
TomJ:    This is about defining the semantics of optional extensions. 
         We should move the gist of this to the section about optional 
GlenD:   Issue: When an optional extension is in a WSD, and you're
         a provider agent, you must implement the extension. 
DBooth:  We need to say what is the meaning of an optional extension,
         that the service MUST support all optional extensions. 
TomJ:    I proposed to move this Note into the section on extensions. 
JMarsh:  We don't have a section on optional extensions. But the same 
         material already appears in the section on Mandatory

RESOLVED: Delete the note from the conformance section (as redundant), 
          and promote the material on optional extensions into its own 
          section, and add "See section ___ for further explanantion". 
ACTION:  Editors to implement resolution to LC5i.

--- Issue LC5j --- 


RESOLVED: Close LC5j as resolved by LC5i. 

--- Issue LC5k --- 


Bijan:    This is just advice for implementers. 
Dbooth:   How about pulling this out into a Note and reworded as a 
RESOLVED: Delete the text, because it is only advice to implementers. 
ACTION:   Editors to implement resolution to LC5k.

Hao:      Why not just use xinclude instead of WSDL include? 
JMarsh:   They are semantically different. 
(Discussion about whether xinclude must be supported.) 
JMarsh:   Our spec starts with the infoset, so how the infoset is 
          obtained is out of scope. 
(Further discussion about potential interop problems if we are silent
about xinclude.) 
Arthur:   Should we specify minimum concrete serialization to guarantee 
JMarsh:   WS-I Profile does that. 
ACTION:   Arthur to submit proposal on conformance requirements for XML
serialization (of WSDL and schema documents) 

--- Issue LC5l --- 


RESOLVED: Leave the Note, but change "processors" to "conformant
processors" (and link to the conformance section), and explain this to
the reviewer. 

RESOLVED: Make the Note in 6.3 normative, and rephrase as "Extensibility
elements SHOULD NOT alter the existing semantics in ways that are likely
to confuse users." 

ACTION: Editors to implement resolution to LC5l.

--- Issue LC6a --- 


RESOLVED: Change {name} in F&P to {uri}.  (I.e., accept reviewer's

ACTION: Editors to implement resolution to LC6a.

--- Issue LC6b --- 


GlenD: The difference is necessary because it will allow schema
processors to validate. It is a co-occurrance constraint. 

RESOLVED: Reject the reviewer's suggestion, explaining that an element 
          Supports schema validation by allowing a co-constraint between
          'value' and 'constraint'.

--- Issue LC6c --- 


RESOLVED: Reject the reviewer's suggestion, and explain that we were
following XML Schema's convention and that it further clarifies that it
is the location of a WSDL document.

--- Issue LC6d --- 


(Discussion of how XPointer schemes work, and namespaces for them.) 

<dorchard> http://www.w3.org/TR/xptr-xmlns/ 

JMarsh: Couldn't reuse our fragments on other media types. 

(Much discussion of Appendix C section C.3.) 

<Jonathan> #xmlns(xp,uri:1) xmlns(wsdl,http;//wsdl)
           xp:xpath(//wsdl:interface[@name='foo']]) interface(foo) 

JMarsh:    Might want to serve a fragment like the line above as XML 
           media type. As the XPath is validated, I don't know if the 
           xpath part is on the component model. 
<sanjiva>  The chair demonstrates his XPointer legacy and prowess. ;-) 
JMarsh:    Two things to identify: either a WSDL component or an XML 
<sanjiva>  Hey, soap's @role can indeed be dereferenced: 
<sanjiva>  http://www.w3.org/2003/05/soap-envelope/role/next 
ACTION:    JMarsh to take issue LC6d to XML Core WG 

RESOLVED:  We should accept the reviewers point about making explicit 
           that we're defining a new scheme. 
ACTION:    Editors to make explicit that we're defining new XPointer
           Fragment schemes.

(Discussion of whether to consolidate the 6 schemes into a single WSDL

The last part of this issue -- "the application/wsdl+xml MIME-type
references this scheme as a possible xpointer scheme - i.e., I don't
think a WSDL resource served as application/xml can be resolved using
this XPointer scheme." -- is postponed pending JMarsh's action item to
talk with XML Core. 

--- Issues LC7, LC10, LC12, LC15 --- 


ACTION:  Editors to implement LC7, LC10, LC12, LC15 unless they find
         problems that require additional group attention.

17:00 Adjourn

Received on Saturday, 18 September 2004 00:42:45 UTC