Minutes, 4 March 2004 WS Description WG FTF

Web Service Description Group
Minutes, FTF meeting 4 Mar 2004
Cannes-Mandelieu, hosted by W3C.

irc: http://www.w3.org/2004/03/04-ws-desc-irc

 David Booth            W3C
 Roberto Chinnici       Sun Microsystems
 Glen Daniels           Sonic Software
 Paul Downey            British Telecommunications
 Youenn Fablet          Canon
 Martin Gudgin          Microsoft
 Hugo Haas              W3C
 Tom Jordahl            Macromedia
 Jacek Kopecky          Systinet
 Kevin Canyang Liu      SAP
 Jonathan Marsh         Chair (Microsoft)
 Jeff Mischkinsky       Oracle
 Jean-Jacques Moreau    Canon
 David Orchard          BEA Systems
 Bijan Parsia           University of Maryland MIND Lab
 Arthur Ryman           IBM
 Igor Sedukhin          Computer Associates
 William Vambenepe      Hewlett-Packard
 Asir Vedamuthu         webMethods
 Sanjiva Weerawarana    IBM
 Umit Yalcinalp         Oracle

 Martin Chapman         WSChor
 Yves Lafon             W3C
 Philippe Le Hegaret    W3C
 Coralie                W3C
 Paul Biron             Health Level 7
 Anish K                Oracle

In addition to the above observers who were present for most of the 
meeting, we had a number of other observers who observed parts of the 

scribe: Igor Sedukhin

Thursday 4 March
08:30 Introductions and logistics
    - Assignment of scribes
        Igor Sedukhin, Umit Yalcinalp, Youenn Fablet, Kevin Liu
        Paul Downey, Jeff Mischkinsky, Asir Vedamuthu, David Orchard 
        Hugo Haas

Igor, Umit, Youenn, Kevin

    - New scribe policy: Since the chair is maintaining the issues list,
      but not the edtodo, the two can easily get out of sync.  Our
      should henceforth include explicit actions to the editors as well
      resolutions of issues.
    - Agenda review 

08:40 WSDL Component Designators:
      Trolling through old minutes does not reveal clearly whether 
      WSDL Component Designators should be added back into the draft 
      as an Appendix.  My memory says "yes, we decided that" but the 
      minutes are unclear and the edtodo does not mention this.  If 
      you clearly remember something different, this is your chance 
      to scream.
Jonathan: WSDL Component Designators should be added back into the draft
          as an Appendix.
[No objection]
ACTION: Editors to add back the WSDL Component Designators back to the 
        spec as SHOULD.

08:43 Correction to minutes on wsdl:ServiceType [2].  Confirm 
      correction to the minutes as enumerated by Umit.

  [2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0224.html

Glen:     This was my proposal and this was resolved at the last F2F.
Umit:     Checked and this was done.
Sanjiva:  Spec is not clear on when service name attribute is required.
Glen will look at that
ACTION:   Glen to look at schema derivation in the current draft

08:45 Issue 79: How much validation? [3]
      Jacek posted a relevant proposal [4].
      David's analysis [5]

  [3] http://www.w3.org/2002/ws/desc/2/06/issues.html#x79
  [4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0121.html
  [5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0234.html

[dbooth: My presentation: 
DB presentation: WSDL Language vs Processor
DBooth:   Separate section in the spec on the processor.
Roberto:  Then we need to add a WSDL editor too.
DBooth:   Yes, maybe. Extract all the statements about what WSDL 
          processor should do and put them together. Such statements 
          are already in the spec, but scattered.
Jonathan: Another pro I was expecting is simplification of the spec.
          Will address the complexity problem by addressing the 
          language in the main spec.
Arthur:   We can spec the language without necessarily calling on the 
DBooth:   WSD is a set of assertions about interacting agents.  WSD 
          only partially describes the interaction.
Umit:     You seem to imply that WSDL is not a complete contract. Does 
          not agree with that.
Glen:     That is actually true, it is not complete.
[JacekK:  Bijan, does David have the defn of monotony right? 8-)]
Umit:     It should be true by looking at the WSDL which must be the 
Bijan:    The original contract may not be sufficient, but why is it 
          not complete?
Glen:     There could be out of band things that WSDL does not capture.
Sanjiva:  WSDL is necessary, but may not be sufficient.
DBooth:   WSDL is a contract, but there could be additional obligations
          Extensions: extensions are non-monotonic.
Glen:     Extension may change the original 'assertion'.
Jacek:    That should not be true.
Bijan:    It depends on the extension. It defines if it is monotonic or
DBooth:   Yes, but we cannot assume.
Jacek:    Binding extension only affects the binding.
Glen:     Except that if it adds default operations in which case it 
          also affects other description component
DBooth:   (from TAG) extension is ID'ed by a qname, target namespace 
          must identify the meaning. Proposed clarification text for 
          6.1.1. Limiting the scope of understanding to the component 
          to which mandatory extension is applied to.
Arthur:   That means existence of such extension may affect the whole 
Glen:     Like in SOAP, look for those .. addressed to you and then 
          look for what you must understand.
Bijan:    The doc means different things depending on how one processes
Roberto:  At least it coerces it.
Kevin:    Is the meaning of the whole component affected by a mandatory
DBooth:   Essentially yes
Glen:     mustUnderstand = required = mandatory. You don't change the 
          meaning of what the binding is.
Bijan:    You could.
DBooth:   Mandatory extension may change some of the assertions 
          expressed in the WSDL spec
Gudge:    Ext mandatory not = it changes the semantics. Do we expect 
          those things to so fundamentally change what is expressed 
          in WSDL.
Glen:     Yes that is possible and we need to craft this into the spec.
Bijan:    What does this mean for validation of the WSDL doc?
Glen:     You can't validate what you don't understand.
Bijan:    If the meaning of the component is changed its validation 
          rules may change too.
DBooth:   The spec is directed towards the meaning of the WSDL 
Glen:     Difficult part is to describe the rules for the extension 
          writers and make sure that does not screw up.
Jeff:     If binding ext adds ops why is it changing the interface?
          What is being validated: the document or how it is 
          processed? Turning this into the context-sensitive language.
          Have to express what the context is.
Kevin:    Agrees with Jeff. If there is a binding and an ext and if I
          only need to understand the binding only and not the ext 
          then why should I care about the ext? With the proposed 
          changes I will need to.
Roberto:  The meaning of the component containing the ext is changed? 
          What if the component was 'built' before the ext was added?
DBooth:   Maybe component is not right word, may be the element.
Jeff:     It feels like the 'foundation of sand'
Jacek:    .. lost ya...
Gudge:    Why is important for service to say the extension is 
DaveO:    Isn't it that the client just does not want to have the 
          error msgs?  It wants to know up front what is required.
Gudge:    Do we anticipate exts that are optional. Are there use cases?
[KevinL:  In the "late bound" case, if there are multiple binding 
          extensions defined under the wsdl:binding component and are 
          all marked with wsdl:required, for a processor who only care 
          about one of the binding extension, why should it be failed 
          if it doesn't understand a binding it doesn't care at all?
          Especially in the "late bound" case where the WSDL file is 
          discovered at run time, and artifacts are generated at run 
          time to communicate with a service.]
Jonathan: Let DBooth proceed.
DBooth:   Optional exts
[pdowney: Trying things out and faulting can reveal your hand - like 
          playing Cluedo..]
DBooth:   Those that do not change the meaning of the WSD assertions.
Glen:     That is not necessarily true.
Bijan:    It is not monotonicity, it is the "ignorability" that is 
          doing it here.  Being monotonic is not a sufficient 
Roberto:  Then adding implicit ops to the interface by an ext will 
          not be optional now?
Glen:     The ext adds those ops if you want to process it.
[JacekK:  <wsdl:binding>
          is this allowed?]
[Bijan:   I.e., optional extensions are optional only for the service 
          client, not the provider.]
Kevin:    Required by who: the consumer or the provider?
Jonathan: WSDL is from the service POV we agreed.
Sanjiva:  Move on
[Bijan:   It's *not* the case that the server is obligated to support 
          all that. At least, that's not the right way to put it. It's 
          a fact of the *language*, that the document won't be *true* 
          unless the server supports all the extension,etc. etc.]
Glen:     Add an issue: is there a difference with client or service 
          obligation with regards to ext.
[Jonathan: New Issue: What is the scope of extensions?]
DBooth:   WSDL defines the way two agents interact and the way to test 
          it is to actually verify if the interactions are as 
Arthur:   Test case: WSDL and the message and assert if the message 
          is conformant to the WSDL. Another one is to give a sequence 
          of messages and assert that against the WSDL.
Glen:     Unless there is an ext that says something about the 
          semantics of the op.
Arthur:   1) is the WSDL consistent 2) is message conformant 3) is the 
          sequence of messages conformant.
DBooth:   We should be able to test anything that the spec says the 
          processor should or should not do. Bottom line: separate 
          the processor from the language.
Jonathan: We can adopt this and close the issue 79.
Tom:      Will this make the spec more or less readable?  Is Jaceks
          proposal on including statements on validation in the spec 
          also with this issue?
Jacek:    Was looking to separate it out.
Glen:     Also wants to keep it separate.
DBooth:   There are simple questions 1) separation of the definition 
          of the language and assertions about the processor.
Glen:     Cares that we have clear expression of that whether or not 
          it is in a separate section.
DBooth:   Can modify the doc and generate the changes that the WG can 
          look at.
Jonathan: Is this simply an editorial issue?
[Bijan:   +1 to cleaning specifying the *semantics* from various bits 
          about arbitrary processors but not moving text around :)]
Tom:      Just state what has to be validated and add this text 
          anywhere in the spec.
[Bijan:   I.e., for each section, you can just add a "Note: A 
          processor that blahblahblah would blahblah blah with this 
Hugo:     There is no impact of what DBooth is proposing on the WG 
Glen:     Let DB do it or reject.
Tom:      Does making these editorial changes address issue 79?
Jonathan: Yes.
Umit:     Will the statements include "conformant processor"?
[GlenD:   as opposed to say "buggy processor"...  All buggy processors
          MUST put $500 into Jacek's bank account.]
Sanjiva:  That would require defining classes of processor, there 
          should be one for clarity.
Jeff:     There has to be the definition of what processor is meant.
          Start with those things that matter for interop.
[.. snip ..]
Jonathan: Just define the meaning of the language :)
Bijan:    Can't entirely *ignore* processing issues when specifying 
          the semantics& different semantics can make processing 
          sane or not.
Sanjiva:  Needs clarification 1) scope of required and that is it.
Arthur:   We are transplanting SOAP approach to WSDL. SOAP has 
          processing model and WSDl doesnt.  Define how processor 
          maps infoset to the component model and that defines 
          conformant processor.
Gudge:    How is that different from the way the spec is now?
[DaveO:   Glen, btw my point about "optional" bindings is that you 
          and I might use the same WSDL, but I implement one binding 
          and you don't. That to me should be ok. If we are both 
          "required", then I should have to.]
Glen:     The issue of "requiredness" is different from separating 
          the processor assertions.
[GlenD:   If we both claim to implement the same WSDL, we both need 
          to be prepared to accept anything which is produced by 
          clients which process that WSDL.  So with bindings, you're 
          right, in that it's unlikely I'm going to implement a WSDL 
          that actually has your endpoint address in it.]
[DaveO:   If they only use required. The whole point of "optional" 
          is that it isn't necessary. :-)]
[GlenD:   But if I put an optional extension in an interface which 
          allows two different behaviors, ANY implementation of that 
          interface must accept both.  That's my point.]
[Bijan:   Hmm. Glen, with features and properties, one can, in some 
          sense, avoid the global scope of extension changes in this 
          way. Extensions can always set properties.  So a binding 
          could set a property. And in the interface, I have a 
          feature parameterized by that property.  Which say, adds 
          an operation (or "enables" an operation).]
[DaveO:   Glen, I disagree. If there are 2 different behaviors that 
          must be accepted, then they should be required, not 
[GlenD:   DaveO: the whole POINT of the optionality is that the 
          client can do EITHER.]
Sanjiva:  "Processor must do x" is ok to use except the extensions 
DBooth:   Should we continue to mix definition of the language and 
          processor assertions?
Sanjiva:  Yes, that is ok.
[GlenD:   And if the client can do one of two behaviors (avec ou 
          sans extension), any implementation which claims to be 
          conformant must accept both.]
Gudge:    Are there places where the processor is implied, but not 
DBooth:   Not sure about that.
Sanjiva:  Right now the processor comes up only in types and 
          extensions. Let's just fix the exts section. Processor 
          assertions in the types section are ok right now.
DBooth:   This does not clarify the requirements on the conformant 
          processor though.
[GlenD:   This discussion has instilled in me a deep and sincere, 
          and in no way optional, desire for caffeine.]
Sanjiva:  No-one has complained about it so far, but there are a lot 
          of complaints about the exts section.
[Gudge:   Gudge concurs with glen]
[JacekK:  Do we keep discussing it or do we just trust the editors, 
          since we're not yet really going to LC?]
Jonathan: However we can have a section on conformant processors that 
          has all the necessary assertions.  Introduce the conformant 
          processor section and solve the two outstanding issues.

11:00 Break

11:30 Issue 79 continued.

Current proposal, add conformance section with:
          1) document conformance: conform to schema, etc.
          2) infoset conformance 
          3) processor conformance (types, exts, Jacek's proposal)
Sanjiva:  3 builds on 1 and 2.
DBooth:   Add to 3) accepts any conformant WSD.
Jonathan: Proposed to the group to accept this
Group did not disagree
RESOLVED: Add conformance section as above.

ACTION:   Editors to incorporate the above proposal.
ACTION:   DBooth to propose specific changes needed for 
          processor conformance text]

[Issue 92, Issue 133 skipped for now.]

10:50 Issue 112: Headers at the abstract level [9]
    - Headers as first-class citizens [10]
    - Glen's OOB feature proposal [11]

  [9] http://www.w3.org/2002/ws/desc/2/06/issues.html#x112
 [10] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0004.html
 [11] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0053.html

DaveO:    Headers are fundamental at the protocol level. Most protocols
          have headers.
Glen:     Two mechanisms now: F&P and the binding. F&P may attribute 
          what data needs to go into the application and then binding 
          could lay it out into the header.
Jonathan: There may not be disagreement that we do it via F&P.
Umit:     The proposal is that F&P is used, but there is an additional 
          1st class construct
Jonathan: There was agreement that we will add such a feature. Close
          with AI on Glen and Yaron to reconcile?
DaveO:    We're not near the consensus there.
Glen:     It is simply side band data, why constrain it at the abstract 
DaveO:    Having it at the abstract level may help apps to decide 
          where to look for such information.  We should take 
          advantage of the SOAP model.
Glen:     It is not good to encourage people to say something must be 
          in the header or not.
Sanjiva:  Can the same feature be used in the component?
Jonathan: Same feature URI can be used repeatedly, yes.
Glen:     F(P*) not necessarily (FP)*.  My proposal has one header 
          (composed of various data)
Sanjiva:  We agreed on F&P mechanism for defining headers on the wire.
Glen:     We still wanted to have a header and not multiple.
Roberto:  If the feature components are different that may be multiple.
Sanjiva:  These proposals have to converge.
Glen/DaveO: That's the problem.
Jonathan: Clarification: application headers vs protocols headers.
Tom:      Defining headers is what people do with WSDL.
Sanjiva:  HTTP has mechanism for both sorts of headers. WSA defines 
          headers for SOAP.
[Yves:    Point of clarification, cookies are NOT in rfc2616 
          (HTTP/1.1 spec), so there are not 2 ways of doing 
          extensions in the spec.]
DaveO:    We're building toolkit that allows both kinds of headers.
Tom:      It should be possible to mix headers and it should not be 
          constrained by WSDL.
DaveO:    To get to consensus: we want a generalized facility and 
          then the other well defined ones.
Glen:     It does not work that way, 1) there are the headers or 
          2) here is the data that appears in the headers
[Will attempt to reconcile positions during lunch.]

12:15 Lunch 

Scribe: Umit

12:40 Issue 112 cont.

[GlenD: <soap:Header>

Jonathan welcomes the schema group members as observers. 

Issue 112: Glen suggests that it should be closed with a future proposal
Glen suggests a strawpoll: 
1. one bag one header for an application header
2. There can be multiple headers for applications. 
3. abstain
Paul:     Is this about SOAP binding or WSDL in general? 
Glen:     We can resolve this by defining one single feature. 
Jonathan: We can solve this by one feature, but we don't have to 
          solve whether this resolves into one or more headers right 
[Anish:   Does proposal one prevent proposal two and vice versa, or 
          is it a question of what we want to encourage?]
Glen:     We will define how it gets resolved in the future for SOAP 
DavidO:   Objects because it makes Glen's proposal accepted.
Correction: Third option is to do nothing, not abstain.
DavidO:   The question is whether there is one place to put app data 
          or be flexible as BEA proposes. 
Sanjiva:  We should close the issue, continue to work on the action 
          item for Glen. We are not done yet with respect to the 
          action item since there are two proposals.
RESOLUTION: Close this issue. Open another one to decide whether there 
          should be a single header vs multiple headers (or both).

14:00 Issue 109: WSDL versioning [12]
    - Use cases (DavidO) [13]
    - Requirements (PaulD) [14]
    - Scenarios
      [***** ACTION: DaveO to write up a proposal for augmenting 
                     schema information to enable versioned data. *****]

 [12] http://www.w3.org/2002/ws/desc/2/06/issues.html#x109
 [13] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0016.html
 [14] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0082.html

PaulD:    Must understand with tag finding should be discussed. 
[DaveO:   My post to schema is at 
PaulD:    If we have WSDLs with versions, the next thing that needs to 
          be discussed how do we refer to them?
DavidO:   There are multiple things that are in WSDL that the Schema 
          group do not care about, but issues about what we do with 
          Schema is relevant to the schema group. Adding operations, 
          etc should be addressed separately. 
Jonathan: The issue is what do we do with documents that have the same 
DavidO:   We use XML schema to describe the messages. Is there a 
          different interpretation of Schema we can use?  Is there a 
          dial in the schema that we can use that allows the 
          extensibility desired? 
PaulB:    If you use a restricted schema, this is possible. If content 
          model is flat and the extra content is at the end, it is 
          deterministic and easy to accept a document. There are two 
          attributes: Validation attempted and validity. 
[HenryT:  Their relation is discussed in detail in the following
          note, which WSD WG members may find helpful:
[asir:    http://www.w3.org/XML/2001/06/validity-outcomes.html is the 
          public version]
PaulB:    If the root node is invalid, you can look down the tree and 
          strip the nodes that are valid unknown.
CMSMCQ:   Paul's algorithm is applicable with Schema 1.0 with the 
          restrictions that are defined. 
Jonathan: There may be a convention we can recommend in WSDL. Is this
[DaveO:   There's a really cool benefit, you don't need wildcards..]
HenryT:   Use global elements and validate twice. Use 1st time what 
          Paul recommends, and validate again. 
Sanjiva:  Why are we talking about this? This is not about WSDL. 
Jonathan: Versioning of schemas is relevant for us. 
Sanjiva:  Perhaps a note from the schema group
DavidO:   If we want to enable someone to take advantage of the 
          double validation, etc. we need to say explicitly say it 
          in WSDL.
Jonathan: Use a style. 
JeffM:    We can be more prescriptive about the way the Schema is used.
[DaveO:   Q: does this require special schema tools]
Paul:     The result of a schema processor should make more 
          information available but it is doable by the current 
CMSMCQ:   Use top level elements. Use what you learn with regular
          languages. The techniques may be recommended for schema 
HenryT:   WSDL should recommend WSDL normalized schemas. With 
          wildcards added at the end. 
Jonathan: If this is solved in Schema 1.1, we can recommend moving 
          to Schema 1.1
HenryT:   We can recommend best practice. 
[HenryT:  The advantage of the two-pass story doesn't require authors 
          to take action.]
DavidO:   Two pass processing does not require the WSDL author to 
          include a wild card. 
[HenryT:  Paul Biron points out that receivers are in control in e.g. 
          the two-pass+surgery story. Whereas in the 
          auto-insert-wildcard(+boundary) story, the receiver has 
          lost control of how strict they want to be.]
PBiron:   Is the extra stuff in the same namespace or not? What are 
          the requirements for the extra stuff?
DavidO:   If there are constraints, that may allow us to get to the 
           point needed. 
Sanjiva:  This is not problem for WSDL. 
[HenryT:  So I understand MSM's suggestion as saying -- "Give me a 
          schema for a WSDL language -- I'll use redefine by extension 
          to make every type, or any subset of types you name, 
          extensible, by redefining by extension with the above]
Sanjiva:  The schema is not defined by WSDL, it comes from somewhere 
[HenryT:  Note this rules out schemas which use 'all' groups (no bad 
          thing :-)]
DavidO:   If there is a mode, WSDL 2.0 can define a WSDL application 
          of schema with the validation rules that are discussed.
DavidEzell <scribe misses some points>. 
DavidO:   We have extensibility and versioning. It is not clear how 
          they overlap. There are instances when versioning and 
          extensibility collide. It is very hard to decide where 
          the boundaries of versioning are. 
DavidEzell: You need to give a hint up front when you have a new 
          version up front, with a new namespace.
JeffM:    We have not decided what we mean by versioning. 
Asir:     Says that the WSDL does not care about the underlying type 
          system, why are we discussing schema specific issues?
Jonathan: We need to specify at least Schema for interop. 
Bijan:    Can we take this out of critical path for Part 1 to meet 
          our timeline?
Jonathan: If we can adopt a marker and best practices, it would help 
          the problem.
DavidO:   I will get my customers to send a last call comment if this 
          is not handled here. 
[Bijan:   Ah, that was what I wanted :)]
DavidO:   we are describing the validity of the message, this is part 
          of the description. 
JeffM:    You have not established what the requirements are. Get a 
          definition of versioning first to move on. 
PaulD:    We are not only using schema, this is intrinsic to WSDL. 
          We generate messages as well.
DavidO:   If it is done with the primer, the functionality will not 
          be in. Put this on the back burner as an issue. If we can 
          close all the other issues, we can come back to this.
Bijan:    Q for David. Lets say have a task force and come up with 
          recommendations? Should they be normative?
DavidO:   Yes. There are range of solutions
Bijan:    If we need to solve this problem, this will affect Part1. 
DBooth:   This is a best practices issue. This can not be normative. 
Sanjiva:  Close this issue right now. We already restrict the 
          messages with XML rules. If there is additional 
          constraints within the schema expressed by schema, it 
          will be perfectly fine. This is a solution offered by 
Jonathan: We need a definite proposal. 
DavidO:   Why aren't the people in this group interested in pursuing 
          with this with Schema wg? 
JacekK:   I am interested in pursuing WSDL construct versioning. 
          Lets move this issue to the primer.
[KevinL:  +1 to move on. I don't believe we agreed to move data 
          versioning to primer.]
[Discussion on whether we should have a joint task force goes on. ]
Jonathan: The mission of the task force is to come up with improvements
          to Part1 and Part2 or Schema itself? 
[sanjiva: I have completed the action item to insert a conformance 
          section - would appreciate if DavidB and others would take 
          a look and propose additional conformance constraints.]
RESOLUTION: Joint tf with Schema and WSDL to investigate whether 
          there may be mechanisms developed. 
RESOLUTION: Close the issue. 
ACTION:   Primer to include best practices and the Schema group to 
          review the best practices language.

15:10 Issue 140: Version attribute [15]
    - Tom's initial proposal [16] and follow-on proposal [17]
      [***** Paul to develop clear enumeration of options *****]

 [15] http://www.w3.org/2002/ws/desc/2/06/issues.html#x136
 [16] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0049.html
 [17] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0069.html

[pdowney: Has posted an attempt to synthesize the versioning discussion:
CMSMCQ:   My perception is that there is a need to point to the version 
          of the schema language. 
KevinL:   Three issues: attribute for defn, define how to use it, 
          version attribute for interface. 
PaulD:    If there are two documents with the same namespace, how do
          you differentiate?  You need to know which is the newer 
Gudge:    The usage of namespace is the same as in schema. 
DavidO:   The reason for a version attribute is to allow compatible 
          changes to be introduced without changing a namespace. 
          Changing a namespace is costly for introducing compatible 
          changes.  We also need to construct a uri from the version 
          attribute in addition.
[pdowney: So is the definitions namespace synonymous with the 
          interface major version ?]
Sanjiva:  We need to make changes to all our components in order to 
          refer to versions of the components. This is drastic change.
[Anish:   +1 to Sanjiva's comment]
Sanjiva:  Versioning of the definition is not meaningful. 
[GlenD:   Wow.  Sanjiva rocks my world.]
JacekK:   Version attribute does not help much except when WSDL is 
          downloaded and you need to refresh/regenerate artifacts.
[DaveO:   +1 to JacekK's pov]
JacekK:   We don't need to say more than that. 
[JacekK:  dbooth, personally, I think checksum or diff is simple 
          enough, but I guess for some people this might vary.]
KevinL:   Optional version attribute will be helpful in the defn 
          elements will be helpful for internal development. 
GlenD:    When definitions have to refer to other documents, the 
          referencing will be problematic. You need to carry the 
          version attribute to make sense of what is being 
          referenced.  There is not much need for this, other than 
          the use case JacekK brought up. 
WilliamV: we should not do anything on this, but if we do we should 
          use the namespace URI to convey version info.
[TomJ:    I think messing with the target namesapce and adding a 
          version convention is not a good idea]
[sanjiva: +1 to it not being a good idea]
Bijan:    There are two aspects to the problem: when to say things 
          are different and how to define relationships between 
JeffM:    This problem is an old problem. The version attribute with
          unspecified semantics is not useful. We need to define 
DavidO:   Schema group has looked into the formal defn of 
          substitutability, acceptable sets, etc.
[pdowney: wanted to state that David and Norm's TAG finding on 
          versioning matches his practical experience]
Igor:     Version is useful at runtime. If one needs to maintain 
          relationship between changes, change management is the 
          place to do it. 
[pdowney: Interesting point from Igor - that actual version could be 
          discovered at runtime.]
Tom:      Describes the details of his proposal. Version attribute 
          indicates a minor revision. 
[MSM:     For the record, the current rough draft of the schema paper
          on accept sets, etc. is at http://www.w3.org/XML/2004/02/xsdv]
Tom:      If WSDL artifacts change, the compatible changes are adding 
          operations, added endpoints. These changes allow the 
          clients with the old versions to still operate. This solves 
          a very well defined set of problems. This is not a solution 
          to the entire versioning problem. 
[DaveO:   big + 1 to Tom.]
[KevinL:  +2]
[igors:   Tom, if someone has changed the wsdl or schema then he has 
          to change the namespace. Things won't work otherwise.]
[Roberto: A hash computed by the consumer of the wsdl would work just
          as well as the version attribute (actually better, because
          the client could decide what the relevant information is)]
[DaveO:   Tom, don't do that.]
RESOLUTION: Close the issue with no action. 

15:45 Break

16:30 Joint Session with TAG (Web arch [21])
    - Saying more about QName mapping (?) [22]
    - Error recovery vs. not having to "validate" parts of the doc not
      used or examined by a processor. [23]
    - Comparison of XML namespaces with Schema and WSDL namespaces. [23]
    - Cracking a component designator URI. [23]
    - Operation safety? (Issue 117) [24]

 [21] http://www.w3.org/TR/2003/WD-webarch-20031209/
 [22] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0164.html
 [23] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0180.html
 [24] http://www.w3.org/2002/ws/desc/2/06/issues.html#x117

[dbooth:  Jacek's WebArch comment from 
          4.5.5 below the Good Practice: QName Mapping - the section 
          (or some other) should probably say more on the 
          interaction of QName Mapping, fragment identifiers in XML 
          (4.5.8) commonly used for this mapping and namespace 
          documents (4.5.4)]
JacekK:   We need a new scenerio to connect sections. 
[dbooth:  WebArch section on QNames: 
[plh-lap: (sections 4.5.5, 4.5.8, 4.5.4)]
Stewart:  If Qnames are going to be used for identification, you need 
          a mapping to URI space. 
JacekK:   However, there is no requirement to use these mapped URIs 
DanC:     The discussion is still going on, there is an error 
          (number?) and the architecture document just reflects 
          the current state.

Next issue:
DanC:     Should be clarified if not clear enough. 
Jonathan: We name abstract components in a targetnamepace. We have 
          taken the namespace to a different level. 
DanC:     How does the qnames and targetnamespace interact? Have you 
          specified how Qnames mapped to URIs? If you have done this,
          you are done.
Jonathan: Do we need the mapping for URIs for the importing mechanisms
          in WSDL? It is ambiguous whether the namespace should be 
          absolutized before adding to the component model.
[Gudge:   Likes the notion of mandating that targetNamespace URIs be 
          absolute to begin with.]
[DaveO:   +1 to absolute URIs. ]
[asir:    +1 to absolute URIs. Simple things should be simple.]
umit:     +1 to absolute URIs
[dbooth:  +1 to absolute URIs]
[jjm:     +1 to URIs, absolutely]
[Chris:   +1 to absolute URIs fwiw]
[Anish:   +1 to absolute absolutely :-)]
[alewis:  +1 to absolute URIs in targetNamespace]
DanC:     Don't canonicalize, just absolutize then compare string by 
Jonathan: There needs to be one mechanism for interop. 
[Stuart:  URI comparison bit in RFC2396bis is at 
ChrisL:   Agrees with DanC (if scribe got it right)
[asir:    My +1 was to mandating that targetNamespace URIs be 
          absolute to begin with]
[Chris:   Mostly - except dan expressed that comparing IRIs either by 
          character or by hex escape was undecided whereas actually 
          the IRI spec says to compare them by character]
Jonathan: Is the relative URI allowed for schema [namespaces] imports? 
[Stuart:  Basic idea is that there are multiple comparison functions. 
          There is one 'identity' function (absolute and then compare 
          character-by-character). Other compariisons must respect
[DaveO:   rfc 2616 says http://www.abc.com and http://www.ABC.com are 
          the same.]
[Chris:   Yes, and http says that foo.org and foo.org:80 are the 
[DaveO:   yup.]
MSM:      If it is not an absolute, it will not work. 
[Stuart:  ie. beyond an identity comparison, other comparisons that 
          compare 'identical' URIs must not say they are different 
          (I think).]
MSM:      Schema does not prescribe behaviour for absolutization.
DBooth:   QName is ambiguous by itself. The mapping should be 
          sensitive to partitioning. 
Stuart:   You need to incorporate partitioning. 

Component Designator URIs: 
[Chris:   you don't have to use http. But a transport that reports 
          the media type is easier, naturally.  So (to summarize) 
          webarch says that the interpretation of a fragid depends 
          on the media type of the resource representation. if you 
          don't fetch one, you don't know which set of rules to apply.]
[Bijan:   (except if you have that information from some other means)]

Issue 117: Operation safety
[dbooth:  Hugo's message: 
[DanC_jam: idempotent(P) iff forAll X P(X) == P(P(X)). 
          # the definition I carry around in my head]
[Bijan:   http://en.wikipedia.org/wiki/Idempotent.  Yep.]
[dbooth:  Hugo's slides: http://www.w3.org/2004/Talks/0304-hh-wsdl/]
[Bijan:   Which isn't what Hugo said. Or, at least not clearly.]
hugo:     Idempotent messages get the same result regardless of the 
          number of times they are repeated.
[Roberto: The bit about side effects for idempotent operations was 
[Bijan:   "same side effect" must mean *the* very same *one*.]
[caribou: http://www.w3.org/TR/2003/WD-ws-gloss-20030808/#idempotent]
[Roberto: right, just one in number]
DanC:     Motivation for safe is important. The lower levels need to 
          know whether the operation is safe or not defined by the 
          person that defines it. 
[Stuart:  There is clearly more to be said about idempotency - see
Bijan:    Is this the only place where we define something about 
          semantics of an operation/Message exchange?
Discussion ensues whether GET operation is safe or not. 
[Stuart:  Idempotency and Safety enter the vocabulary from RFC 2616 
          Section 9.1 (HTTP 1.1 spec)
Bijan:    Safety is context dependent. 
Sanjiva:  From WSDL perspective, the question is whether we should do 
          the marking of safeness at the abstract level or not. 
[Stuart:  BTW defn of idempotency n RFC 2616 is not very adequate 
          either (side-effect free)]
Arthur:   Most of the Web is for information retrieval. It is a good 
          idea to mark safety at the abstract level. 
Glen:     Is it possible to break the safeness in different levels in 
          WSDL by adding additional headers, etc? 
JacekK:   It's not yet clear if an operation identifies a piece of 
          functionality or not, because if not, we cannot mark an 
          operation as safe as that depends on the functionality 
          behind the operation.]
[Chris:   Yeah, it has the same result every time ....]
Stuart:   There is no way to make the WSDL generator to define an 
          operation to be safe for bottom up case.
[DanC_jam: Yeah... what he's saying.]
[Chris:   Modula-3 allows modules to be marked as 'unsafe' meaning 
          they use untyped memory access.]
Arthur:   For top down, it is relevant to be able to mark operations 
          as safe. 
[pdowney: +1 to Arthur]
[DanC_jam: I heard Arthur mention several programming languages with 
          a relevant notion of safeness: const in C++, .Net attributes,
          Java 1.5 something.]
KevinL:   What is the safeness mean for the client of the service? 
          Why is this useful? 
[asir:    according to Hugo, e-mail, - a safe operation is cacheable; 
          it may be serializable as an HTTP GET (or even HEAD) request; 
          if so, the request can take advantage of the Web 
          infrastructure such as caches.  A toolkit could make the 
          choice of using an HTTP GET or SOAP GET binding for such 
          operations (e.g. GetStockQuote) if there where marked as 
          such.  Knowing that an operation is safe or idempotent 
          can allow poor-man's message reliability, or message 
          reliability optimizations: safe and idempotent operations 
          can be repeated without additional side-effects, and 
          therefore this eliminates the problem of ensuring that a 
          message is received only once.]
[Chris:   http://en.wikipedia.org/wiki/Idempotent]
Jonathan: An example is when your credit card is going to be charged 
          and you are informed on the web. 
[Chris:   In user interface design, a button can be called 
          "idempotent" if pressing it more than once will have the 
          same effect as pressing it once. For example, a "Pause" 
          button is not idempotent if it toggles the paused state. 
          On the other hand, if pressing it multiple times keeps 
          the system paused and pressing "Play" resumes, then 
          "Pause" is idempotent. This is useful in interfaces such 
          as infrared remote controls and touch screens where the 
          user may not be sure of havin...]
DanC:     Web Architecture has already defined. 
SAnjiva:  It is not covered for all the MEPs that exist in WSDL. We 
          have to define it for any pattern. 
[Stuart:  FWIW see RFC 2616 "9.1.1 Safe Methods"]
[Arthur:  I said that Java 1.5 will have code attributes, so even 
          though there is no language syntax to mark a method as 
          safe, you could define a code attribute to mark a method 
          as safe. In C++ you can mark a method as const which means 
          it doesn't modify the object.]
[Roberto: minor nitpick: they are called "program annotations", or 
          simply "annotations"]
Chris:    Safe does not mean that anything bad will not happen, for 
          example downloading illegal material from the web may be a 
          safe operation.
[Chris:   because no additional obligations were incurred]
[Arthur:  In .NET there are code attributes and these are used for 
          Web services, so you could also define a new .NET code 
          attribute to mark a method as safe.]
PaulD:    Worries that 'safe' is just one instance of a generic 
          problem - how to publish policy.
DBooth:   We need to clarify that the safety is from the perspective 
          of the client for any MEP.
DAnC:     The only requirement that I can speak for is the 
          Request/Response (In-out) pattern
Phillipe: Section 3.5 of the Web Arch docuement will suffice
[DanC_jam: (I don't know whether "input messages" get exposed 
          sufficiently to designers)]
Jonathan: Lets refer to HTTP or web architecture document.
[dbooth:  DanC, yes in WSDL they do get exposed to the designer to 
          the same degree as operations.]
Glen:     Has an issue for addressing interactions with extensions.
JacekK:   Do we expect/agree when we have an operation in an 
          interface that we can assign semantic to an operation?
          This is the same problem, because assigning safeness is 
          adding semantics. 

[Chair recalls Joint session TAG ended at about this point.]

[Discussion onto whether the operation carries semantic or not.]
Gudge:    What are we looking for? To label an operation "safe" in 
          the same way the HTTP GET is safe? 
Sanjiva:  This may not work in general, but we are asked just to add a 
          mechanism to enable marking safeness. 
[TomJ:    If we have to add it because the tag will demand it, lets
          just stick some syntax in there and we can be done with it.]
[KevinL:  +1, but that syntax must be optional]
[plh-lap: 1. safe='yes'
          2. safe='http://..../safe'
          3a. feature/properties (we define the uris)
          3b. feature (we define the uri) / property (we reuse
[sanjiva: +1 for (1)]
The wg starts discussing whether the safeness should be expressed via 
feature (hugo), a simple property (Tom), feature at the abstract 
level (and property at the binding), etc.
[anish: +1 to feature -> webMethod]
Proposal: Add an attribute on operation, default to false to indicate 
          the safeness. 
[KevinL:  against default to false. If not specified, it means no 
          claim is made.]
[asir:    SOAP 1.2 - Underlying protocols designed for use on the 
          World Wide Web provide for manipulation of resources using 
          a small set of Web methods such as GET, PUT, POST, and 
          DELETE. These methods are formally defined in the HTTP 
          specification [RFC 2616], but other underlying protocols 
          might also support them. Bindings to HTTP or such other 
          protocols SHOULD use the SOAP Web Method feature to give 
          applications control over the Web methods to be used when 
          sending a S...]
Glen:     This is the same as setting the webMethod to GET. 
[plh-lap: -1 to reuse the webMethod get property]
Jonathan: We will have duplicate information if we need to specify 
          the web method in the binding as well as the abstract level.
Sanjiva:  Proposal: Add a safety property to the interface operation 
[plh-lap: Property?]
[anish:   Is the WSDL then going specify exactly what is meant by 
[plh-lap: We point to the web architecture]
Roberto:  Property syntax is better because it can mark interfaces to 
          be safe instead of defining it on operation.
[plh-lap: And if people don't like the definition of safe in web 
          architecture, they should fix the web architecture.]
Glen:     There is no reason to add anything to the component model.
The wg continues to discuss properties in component model vs features 
& properties.
[Arthur:  e.g. ASP.NET happily exposes every operation of a Web 
          service as SOAP/HTTP, HTTP GET and HTTP POST]
Straw Poll:
  1. boolean property to operation component
  2. use property (from F&P) to designate safety. 
7 in favor of 1
8 in favor of 2
Resolution: We don't have a strong preference. 
Bijan: redo the strawpoll. 
Boolean property in favor 8
F&P : 8

[Chair asks who cannot live with the approaches, there are some on 
each side.  Chair adjourns meeting, will figure out a procedure for
moving forward before tomorrow.]
[hugo: Hugo's slides: http://www.w3.org/2004/Talks/0304-hh-wsdl/]

[Issues 123, 117, @wsdlLocation skipped for now.]

Received on Tuesday, 9 March 2004 11:41:06 UTC