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

Minutes, 5 March 2004 WS Description WG FTF

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Tue, 9 Mar 2004 08:41:05 -0800
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA202DA7715@RED-MSG-30.redmond.corp.microsoft.com>
To: "WS Description List" <www-ws-desc@w3.org>

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

irc: http://www.w3.org/2004/03/05-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: Youenn

Friday 5 March
08:30 Issue 124: Semantics of mandatory properties and features [30]

 [30] http://www.w3.org/2002/ws/desc/2/06/issues.html#x124

Tomj:     We discussed the proposal and we made some modifications. 
          Where are they ?
ACTION:   Editors to clarify the spec to say that wsdl:required 
          attribute means that a feature must be understood and 
          it must be engaged.
RESOLUTION: Issue 124 closed

08:45 Issue 149: Duplicate features with conflicting @required [31]

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

ACTION:   Editors to clarify that the strongest value of the 
          @wsdl:required attribute wins.
RESOLUTION: issue 149 closed

09:00 Issue 134: Proposal for adding Compositors [32]

 [32] http://www.w3.org/2002/ws/desc/2/06/issues.html#x112

Paul:     f&p plus compositors should be modularized
William:  Iis the compositor thing reusable in non WSDL space?
[Gudge:   +1 from Gudge on modularizing f&p (and anything else that 
          goes with them)]
[KevinL:  +2]
[Gudge:   Proposal is at 
Roberto:  It would also work outside a wsdl.
[Bijan:   Gudge, I've long been in favor of adding stuff as extensions,
[Gudge:   but... ?]
[Bijan:   The question is how to do these extensions so that the 
          proponents are satisfied that it will get the requisite 
Jeffm:    Need more than NANDS, choice, oneOrMore are all interesting
[Bijan:   Right now "do it as an extension" == (in most people's mind) 
          "screw you, it ain't getting standardized". So, there's *no 
          value* to people in this group in taking what *they* propose 
          and making it a (separate) extension.]
KevinL:   Can we do without compositors in WSDL 2.0? Does it hurt?
[Bijan:   I.e., the problem is social, not technical.]
Roberto:  Analogy between soap:binding/soap:fault and 
          f&p/compositors in real cases, soap:fault happens
TomJ:     Asked what happens if you don't use compositors Answer: 
          implicit AND. If we have implicit AND do we need a compositor 
          for it?]
Umit:     Compositors is applicable to all extension space, it is 
KevinL:   If the compositor proposal is about composition of extensions,

          it is a general idea. If the compositor is only about F&P 
          it should be considered together.
Sanjiva:  Curious that compositors are so critical that it does not 
          appear sooner.
[KevinL:  Continuing what I didn't get a chance to finish - If it's 
          a general proposal for a new feature, we have been trying 
          a long time to have a last call, I don't think we want to 
          take any new features.]
Bijan:    What about relationship between compositors and 
          wsdl:required attributes?
Jeffm:    We have more power by introducing it, it is more convenient.
          We are picking the minimal set to solve most problems not 
          all of them.
Gudge:    f&p are incomplete. I am surprised that we should add 
          functionality to incomplete f&p.
Umit:     We have a pb with the extension mechanism. this proposal 
          tries to fix this
William:  Does this proposal solve the overlapping problem of f&p?
Glen:     No, this pb is too hard.
Bijan:    Do implementers feel comfortable with that proposal?
Umit:     This proposal came from my product people, they wanted it...
Paul:     It would be a pb to have both this mechanism and the 
          policy mechanism ...
[anish:   paul - what is the spec that is in direct competition?]
Glen:     I have thought about the implementation of this proposal 
          and it seems ok.  This syntax seems compatible with the 
          other syntax.
Paul:     Analogy policy/compositors and literal/encoded. Have only 
          one is better
KevinL:   Having this in WSDL forces us to implement it. We think 
          that the decision should be made in another space.
Tomj:     The WSDL can become very complex.
Glen:     It would simplify things.
[KevinL:  What I wanted to say: implementing this in WSDL2.0 force 
          us to make a choice in a premature manner.]
Jeffm:    We may limit the recursivity depths of compositors.
Umit:     Two or three levels of nesting are generally sufficient.
TomJ:     while on the surface the implementation doesn't seem like 
          it would be bad, the nesting ability is very worrying 
          and could introduce many problems.
[Roberto: Technically, aren't two levels enough? we could use CNF...]
[Paul:    Want's to vote on moving compositors out of part 1]
Sanjiva:  Do you see the need to associate features only inside WSDL 
          or could it be made outside WSDL?
[pdowney: +1 to no WSDL, no Web service as a notion.]
Jeffm:    It is appropriate to use within WSDL because this is 
[jjm:     Glen (responding to Sanjiva): possibly the latter, but at 
          least the former]
Bijan:    Compositors defined as uri, is the extension really needed?
Glen:     We could fix this and change the syntax.
Bijan:    Could it be done with schema?
Glen and Umit: no 
[TomJ:    Removing the URIs and replacing with simple values 
          ("and" "or" etc) would make the proposal better in my 
Strawpoll: are you in favour of adding the compositor proposal ?
  yes: 7
  no: 8
[dbooth:  How many cannot live with adding compositors? Yes: 6 ]
[dbooth:  How many cannot live with NOT adding compositors? Yes: 3]
[dbooth:  Formal vote about adding the compositor proposal to our 
Philippe: Recaps what is a formal vote. Recaps what is a "feature 
          at risk."

Vote: adding the compositor proposal in the proposal:
  IBM: no
  Macromedia: no
  Sun: yes
  Ccanon: yes
  webmethods: no
  HP: no
  SAP: no
  BT: no
  CA: abstain
  W3C: no
  University of m: abstain
  Oracle: yes
  Systinet: no
  Sonic: yes
  Microsoft: no
no: 9
yes: 4

RESOLUTION: Issue closed with No Action.

Sun, Canon, Oracle, Sonic plan to file minority opinion.

Sanjiva:  Is the primer going within the recommendation process ?
Jonathan: In our case yes
DavidB:   This document is not normative, the need to put it in 
          recommendation track is low.
Hugo:     Charter tells us that the primer will be in rec track.
Paul:     Part 2 & 3 will have normative data ? Could we have a 
          normative extension in part 2,3?
Sanjiva:  Yes.

[Decide to tackle some issues postponed from yesterday.]

09:50 Issue 121: Broken resolution of NCNAME or QNAME [6]

  [6] http://www.w3.org/2002/ws/desc/2/06/issues.html#x121

Roberto:  Issue is that we do not say that we have 
          undereferencable namespaces.
Sanjiva:  This is an error.
Gudge:    What type of error?  If we do not use that part of a 
          WSDL, this is not an error.
All:      Yes.
Asir:     Schema defines how to dereference qnames. What about 
          the WSDL spec?
Sanjiva:  This is already in the spec.
Gudge:    Have we eliminated all NCNAME reference use? If not, 
          we should.
Sanjiva:  I will check the fault section
ACTION:   Editors to add clarification text with regards to issue 121
RESOLUTION: issue 121 closed

09:55 Issue 92: Layering message patterns [7]

  [7] http://www.w3.org/2002/ws/desc/2/06/issues.html#x92
[Sanjiva: Youenn (original proposer) noted that this is now obsolete]
Youenn:   This issue is obsolete with the MEP decisions we made.
RESOLUTION: issue 92 closed without action

10:00 Issue 133: Why aren't two input/output elements allowed to share 
      the same @element value? [8]

  [8] http://www.w3.org/2002/ws/desc/2/06/issues.html#x133

Sanjiva:  We can solve this with a wrapper and a choice element in it.
Tomj:     The reason to not allow this is that this is overcomplicated
DavidB:   You can do that by defining two operations.
Jonathan: We removed it intentionally as a by-product of the message 
RESOLUTION: issue 133 closed (this is intentional)
 [Sanjiva: we note that issue 133 is a by-product of the removing 
          <message> discussion. If you want to have alternate actual 
          elements for a message reference (label) of a MEP then you
          have to define a wrapper element with a schema and use that.
          Alternatively DavidB suggested one could define two 
          operations and achieve the same result (different input 
          same output).]

10:10 @wsdlLocation
      [***** Awaiting proposal from Umit, basically copying 
             xsi:schemaLocation *****]

[asir:    where is the proposal?]
[hugo:    Proposal: 
Umit:     Define an optional @wsdlLocation that would appear in 
          wsdl:ServiceType in the WSDL schema.
Arthur:   You say that you only want one attribute in the service 
          element. Should it not be a global attribute?  We have a need
          in policy statements to refer to WSDL components. Then 
          there is a need to find the description of a component.
Umit:     This is a new requirement. My proposal is smaller.
JacekK:   In the smaller problem I suggest using wsdl:import instead 
          of wsdlLocation.
Roberto:  We should fix the general pb and consider Arthur's amendment 
          as a friendly one.
Jonathan: There is an interaction between this and the import 
TomJ:     Asks if we add wsdlLocation how does this affect the 
          <service> element in WSDL?
Answer:   Why does it matter? Why do you care?
[GlenD:   Still don't get why would anyone care if it's on the 
          service element?]
[Sanjiva: What are the semantics of service/@wsdlLocation?]
Arthur:   I made a proposal (a global element) and you made 
          modifications on it.
[Sanjiva: And how does it interact with wsdl:import]
[GlenD:   It doesn't interact with wsdl:import]
Arthur:   There are three proposals in fact
[GlenD:   If you've already imported stuff at the top, the 
          wsdlLocation hint would get ignored. If you refer to 
          things directly inside <service> which are not yet 
          imported, wsdlLocation would be used just like it would 
          in a service reference context.]
Umit:     If we follow the global attribute proposal, we need to 
          define what it is if put in any xml element.
Gudge:    wsdl:schemaLocation should follow xsi:schemaLocation.
          xsi:schemaLocation cannot be put within a schema definition.
          We can put it in soap messages or any xml element.
Roberto:  +1 to the global attribute 
Glen:     This might be an alternate way to import things within the 
          <service> element only if we follow Umit's proposal
[pvb:     xsi:type *IS* allowed in schemas just as any foreign 
          attributes are allowed. On any element in the schema 
[Gudge:   Gudge would like to know where the serviceType stuff is 
          in the spec?]
Umit:     It is not clear that we can do what schema does, that is 
          why I have narrowed the proposal.  I would be interested 
          in a text explaining the semantics of this attribute in 
          any xml element.
Tomj:     I do not know what it means to make wsdlLocation a global 
Umit:     Problem is when I have a service reference, I have qname 
          references and I want to find them
Tomj:     When having a service reference, I need to resolve the 
          references. I do not understand why it is interesting to 
          solve this response in every place.
Sanjiva:  Bpel is a use case for global attributes.
Umit:     Bpel and ws-policy are the only use cases for the moment, 
          which are out of scope.
Sanjiva:  Service reference is in the editor's draft in the service 
          element section.
DavidB:   Service reference is only in a note.
Sanjiva:  It does not need to be normative, you can also do service 
          reference in other ways.
Strawpoll: should we add some kind of wsdl location somewhere?
  yes: 11
  no: 0
Jonathan: We will add one of these proposals
Asir:     I would like to see an example
Sanjiva:  Example of global attribute, inside a bpel when i reference 
          a porttype it would be convenient to say where to get the 
          wsdl description.
Jonathan: We would take this attribute in a separate ns, as xsi/xsd ns
Jeffm:    Umit proposal is scoped to the service reference
Strawpoll: Would you like to add something along the lines of Umit's 
  9 in favor
strawpoll: Would you like to add something like a global attribute 
  14 in favor
Arthur:   My proposal was modeled along the xsi:schemaLocation, the 
          semantics are very clear.  That is very clear in the schema 
          spec, we just need to be very clear in the wsdl spec
ACTION:   Editors to write in the spec the wsdlLocation global 
          attribute proposal along what has been done for 
RESOLUTION: close the wsdlLocation attribute and add a wsdlLocation 
          global attribute.

[Arthur:  Fyi, the wsdlLocation attribute was discussed at the 
          September f2f where is was called descriptionLocation 
[Arthur:  fyi, example of wsdl:descriptionLocation appears in 
10:50 Break

11:20 Issue 120: Operation Name feature proposal [33, 34, 35]
    - Mark Baker had some comments [36, 37].
    - Request for being able to detect where the OperationName is
      located (Mark Baker) [38]
    - First message only, or in responses? (Jacek) [39]

 [33] http://www.w3.org/2002/ws/desc/2/06/issues.html#x120
 [34] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0082.html
 [35] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0152.html
 [36] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0173.html
 [37] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0175.html
 [38] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0105.html
 [39] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0165.html

Umit:     There is a problem in identifying the operation from the 
          message exchange (uniqueness on the wire pb)
[dbooth:  It seems that this feature is intended to make it easier for
          a WS to determine which operation was intended when two 
          operations use the same input message schema. The separation
          of the abstract interface from the binding details provides
          a nice conceptual separation between information that is
          semantically significant to the application, and information
          that is just related to the mechanics of the interaction.
          The question of which operation to invoke seems very 
          semantically significant to the application.  Therefore, it
          seems odd that such semantically significant information
          would not be indicated in the message itself. So I am mildly
          not in favor.]
[Umit:    The answer to David's question is that if it needs to be 
          indicated in the message, there needs to be a well defined
          place that is defined. ]
Gudge:    Along the lines of David, interfaces should have operations
          with different messages
[dbooth:  Anish, no. I think it's the app's problem if it designs its
          message schemas in a way that it can't figure out what
          operation is intended. In fact, some apps may choose to
          dispatch the operation based on the *values* of the data
          in the message, rather than differences in the message
Youenn:   We should at least address the pb somewhere in the spec.
Sanjiva:  This is the server's problem, server does not need to 
          expose how it handles that in the WSDL.  What should be 
          described in the WSDL is what the client should do.
[anish:   ok. thx. follow up questions -- what does an operation 
          mean then? Most people have a certain thing in mind when
          they come across the word 'operation'. Are you saying that
          operation is just a syntactic construct that does not have
          a meaning?]
[pdowney: Wants support for both modes of 'operation' as this helps
          him unify document and rpc camps]
Glen:     Pb is when someone takes a wsdl for standardization, and 
          another one implements it. This proposal allows solving 
          this pb.
[dbooth:  anish, yes. An operation is just a syntactic place in the 
          WSDL document for indicating the message types and MEP.]
Glen:     Adding a feature will guarantee that dispatching must be 
          made in some way.
Umit:     This is a pb that has been identified by WS-I. They 
          constrained the services to have uniqueness on the wire.
          Therefore there is a problem.
Sanjiva:  This is not a problem for a client (just need to follow 
          the rules), but there is a problem when a service 
          implementer picks an existing wSDL.  Just need to introduce
          a header per operation at the binding level.
[pdowney: Was WS-I a 'solution' or a 'hack' ?]
Hugo:     Will the current state spec be profiled by WS-I ?
Jonathan: Even this proposal would be profiled.
Sanjiva:  Proposal adds an extension that might need to be profiled.
Glen:     But it is clear what the feature does.
Anish:    BP put the uniqueness on the wire requirement because that 
          was a real interoperability problem for web service users.
Sanjiva:  The point is that you can solve this problem without 
          adding a new feature (header, soapaction).
[GlenD:   No, David, because that was the original motivation for 
          the uniqueness proposal.]
Sanjiva:  The pb happens when two people implement the same WSDL. We
          could say somewhere that if a WSDL writer wants everybody
          to implement their service, they need to take care of that 
          problem with already known solutions.
Glen:     The other cases is intermediaries. Intermediaries can see 
          in the WSDL that it is this header that defines the operation
[Umit:    To answer to Sanjiva, there may be multiple ways of doing 
          this, but not having one way of doing it will lead to 
          interop problems. ]
[Anish:   It all depends on the way you look at it (hack v. solution).
          The confining parameters were - WSDL 1.1]
[Umit:    We need to limit the choices and define a well-scoped 
          solution. ]
Glen:     Analogy with styles: when i see rpc style, I assert that
          the schema is built this way, I can check or not.
Jonathan: I have a service with soap messages and ws-Addressing blocks. 
          What should I do for my WSDL description? Discussions about 
          policies, WS-Addressing relationships with features.
Glen:     You need to write a new feature spec without changing the 
          WS-Adressing spec
[Roberto: Tasty]
Sanjiva:  What is the meaning of required features?  Required features 
          should be part of the WSDL component model.
Gudge:    All interfaces will have this feature on/required.
DavidB:   We already rejected the uniqueness on the wire constraint.
          There is another way to solve this: a style attribute on the 
          interface.  The style attribute saying that all geds 
          referenced in the interface are different
[DaveO:   Sigh. I don't get it. Why make a "property/feature" that 
          says the uniqueness, why not just make that part of the 
          definition of the operation. oh well.]
Discussions about relationships between rpc style and uniqueness on the
wire. Rpc style does not span operations and therefore does not really 
solve this problem
Glen:     The abstract feature says the dispatch info is somewhere in 
          the message.
[pdowney: Thinks this will kill operations. People will just write a 
          single operation per interface "stuffHappens" ]
William:  What will I need to do if I have an interface with all 
          message geds different?
Glen:     You will put davidB uri in the interface that states that 
          you are implementing the dispatching feature through unique 
Sanjiva:  If we accept this proposal, for each endpoint, somewhere in 
          the WSDL, there will be an assertion that says I implement 
          the dispatch through a mechanism.  Default value being that 
          amended rpc style will do that for you.
Glen:         Proposal is then that a wsdl writer will not need anything

          more if geds are unique and if not, he needs to fix it...
strawpoll: Should we add this uniqueness on the wire proposal
  yes: 8
  no: 7
Who could not live with the proposal? 3
Who could not live without the proposal? 4
Formal vote: should we add the uniqueness on the wire proposal
  BEA: no
  Sonic: yes
  Systinet abstain
  Oracle: yes
  Mindlab: abstain
  W3C: abstain
  CA: abstain
  Microsoft: no
  BT: no
  SAP: no
  HP: abstain
  webMethods: abstain
  Canon: yes
  Sun: yes
  Macromedia: no
6 no against 4 yes
RESOLUTION: closed issue 120 by not taking any action
[Expect some minority opinions on this one too.]

[KevinL:  Is there a 80/20 case? I worry that we are spending too 
          much time resolving a minor problem. if it's not RPC style, 
          how much is the chance that two operations refer to the 
          same message in multiple operation?]
[pdowney: does the same rule apply to telecons ?]

12:15 Upcoming FTF:

Next f2f will be from the 19th of may to the 21st of may, thursday 
afternoon having task force/informal discussions.
[Jonathan: http://www.w3.org/Guide/staff-contact]

12:20 Lunch

Scribe: KevinL

13:30 Issue 117: Marking operations as 'safe' [19]
    - Hugo's proposal [20]  

 [19] http://www.w3.org/2002/ws/desc/2/06/issues.html#x117
 [20] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0246.html

Continue from yesterday's discussion: marking operation as safe.
Strawpoll: who wants to add to component model for operation safety
  yes: 7
  no: 3
Formal Vote: 
  option 1: add new property in component model on operation component.
  option 2: introduce an operation safety feature.
[dbooth:  (Option 2 means "feature" in the sense of "features and 
TomJ:     Option 1 means make it a top level property of operation, 
          same level as operation name
vote result:
  IBM 1
  Macromedia 1
  SUN 2
  Canon 2
  HP abstain
  WebMethods 1
  SAP 1
  BT 1
  Microsoft 1
  W3C abstain
  CA abstain
  Oracle 2
  UofM abstain
  Systinet 2
  Sonic 2
  BEA 1
Total: 7 for option 1, 5 for option 2
Jonathan: Objections to syntax: an boolean attribute for 
          interface/operation?  Do we need ability to set the value 
          of this attribute for a set of operations?
[No objections recorded.]
[JacekK:  http://www.w3.org/TR/webarch/#safe-interaction]
[JacekK:  defn of "safe"]
ACTION:   Editor to add optional Boolean "safe" attribute to interface
          operation, corresponding property in the component model.
RESOLUTION: close issue 117 with action to editor to add an optional 
          boolean safe attribute to interface operation
[dbooth:  WebArch definition of "safe" operation: 
ACTION:   DavidO to notify TAG about or decision

14:00 Issue 123: Requiring all operations to be bound [18]

 [18] http://www.w3.org/2002/ws/desc/2/06/issues.html#x123

Jonathan: issue from Yaron. 
TomJ:     Recaps Yaron's message
PaulD:    Is it the case that it's not possible?
Sanjiva:  We have already decided not allowing partial binding.
PaulD:    Sounds issue is already resolved.
more discussion, just need clarification in spec
ACTION:   Editors to further clarify the spec to make clear that 
          all operations must be bound.
[Gudge:   presumably in part 3]
RESOLUTION: Editors to add further clarify the spec to make clear that
          all operations must be bound.

13:30 Import/include issues
    - 127: Behavior if import/include fails [40]
    - 128: Two imports for the same namespace illegal? [41] 
    - 129: Allow multiple values for import/include locations [42]

 [40] http://www.w3.org/2002/ws/desc/2/06/issues.html#x127
 [41] http://www.w3.org/2002/ws/desc/2/06/issues.html#x128
 [42] http://www.w3.org/2002/ws/desc/2/06/issues.html#x129

[TomJ:    Issue 127:
[Anish:   Isn't the location just a hint?]
Gudge:    Question is what if I see import and I don't have a 
[Anish:   What if the import is being used for a particular binding,
          and I don't care about that particular binding?  i.e., i 
          don't process that binding?]
[Asir:    If the location is absent, then may be, processor is aware
          of those components]
Umit:     We should explicitly spec the behavior when location info 
          is not available.
[pvb:     Need to say a little bit on both semantics of import and 
          in qname resolution...very brief]
[Umit:    Correction to scribe: what I am suggesting is that this is 
          a qname resolution issue, not necessarily whether the import
          attempted fails or succeeds.]
Paul:     In schema, if import is a failure, many processor just 
          display a warning,and move on
[pvb:     +1 to what Gudge is saying]
Gudge:    We already have qname resolution, just need to make it 
ACTION:   Editors to clarify the spec to say that its ok to have bad 
          imports but if during QName resolution you can't find 
          something then it fails like any other qname resolution 
[Asir:    Is there something called as WSDL document location 
          strategy (aka similar to schema document location strategy) 
          in WSDL spec?]
[pvb:     A processor which faults when in import "fails" should be 
          out of conformance with the spec]
[Asir:    Schema document location strategy is 
RESOLUTION: close issue 127 by assign editor action to clarify the 
          spec to say that its ok to have bad imports but if during 
          QName resolution you can't find something then it fails 
          like any other qname resolution issue.
[pvb:     Does wsdl have chamillion include?]
[Umit:    +1 to Gudge]
[Asir:    No WSDL does not have chameleon include :-)]
Gudge:    Let's say split a namespaces into 3 documents, then import 
More discussion on Gudge's case
[Asir:    schemaLocation is a required attribute in XML Schema 
Gudge:    Feels inconsistent with the decision we made on import.
[Asir:    See http://www.w3.org/TR/xmlschema-1/#compound-schema]
Jacek:    Import behaves differently
Gudge:    Why do we need to fail early for include?
Tomj:     Include is from same ns, import is not
Strawpoll: want to fail include early? 
strawpoll: want to treat include same as import?
[dbooth:  Since this would be a constraint on a WSDL processor, 
          do we want to require ALL conformant WSDL processors 
          to fail early?]
scribe was too fast to put down a resolution for issue 127 already, 
is ready to document a revised resolution
[pdowney: Doesn't want to describe beahviour of a "processor" here 
          or understand how you would tell if it failed early or 
[Sanjiva: igor: if an included document has a <service> element then 
          not doing early processing of <include> will break the 
          world because that <service> will not ever be found]
More discussion if "require" to fail is necessary.
Jacek:    We can either make what to include available early or to 
          allow import from same ns
[pvb:     I was wrong, the xs:include/@schemaLocation is required. 
          But, it says "It is not an error for the *actual value*
          of the schemaLocation [attribute] to fail to resolve it 
          all, in which case no corresponding inclusion is 
          performed.", in section 4.2.1]
Straw poll: do you want to fail early for include?
straw poll: treat include same as import?
JacekK:   There are two usecases, I suggest solving by allowing 
          import for the same namespace and early failure for 
RESOLUTION: include will fail early (immediately).
[pdowney: how does this fit in with dbooth's work on document (v) 
          processor ?]
ACTION:   Editors to update draft to say that include will fail early.
[pdowney: how do i write a testcase for "fails early" ?]
[TomJ:    You include a file that doesn't exists and check for 
[igors:   to scribe: another clarification to my point is that if 
          one does <include> of a document with <service> tags, then
          unless it is mandatory to early process the inclides some
          will find those <service> definition and some would assume
          they don't exist. Such ambiguity is a problem for the 

Topic Issue 128: Two imports for the same namespace illegal?

Arthur, Glen, Gudge...: You can have as many import from the same 
          ns as you want as long as they are consistent.
[anish:   +1 to Arthur. That would encourage people to do it]
[pvb:     Schema includes a non-normative that says just what 
          Gudge is asking for.]
RESOLUTION: Editor to add to spec to explicitly allow >2 imports 
            from same ns.
[Anish:   Why do we want to encourage folks to do this. It is ok 
          if they do it, but why encourage?]
ACTION:   Editors to add text saying two imports with same 
          import/@targetNamespace is legal]

Gudge:    We should have a different decision for include
Many nos from group
DavidO:   Will this force people to design their ns in certain way?
[JacekK:  NEW ISSUE: allowing imports for the same namespace as 
          the targetNamespace of the importing document?]
[Gudge:   Gudge, no to Jacek's NEW ISSUE]
[pdowney: Just wants greater clarity on import and include - lots 
          of work done on this in SB and WS-I and is even more 

Topic Issue 129: Allow multiple values for import/include locations
see http://www.w3.org/2002/ws/desc/2/06/issues.html#x129
 [Sanjiva: Proposal change include to: <include 
          locations="uri1 .. urin"/> and then get the stuff from 
          whichever URI from that list]
[Arthur:  Yaron is proposing a failover mechanism, i.e. if url1 
          fails try url2 etc.]
Jonathan: Is there a proposal for include to have multiple locations?
Jacekk:   How is it different: change include to have multiple 
          locations, or all multiple imports from same ns?
[Sanjiva: Yes it is different because of the failure rule we have 
          adopted for include.]
Straw poll: make include a list of uris
  in favor 5
  no 10
[Sanjiva: no objections to recording consensus]
RESOLUTION: for issue 129: not make import/include take a list 
            of URIs. close with no action.

15:00 Break

[Jonathan:  Reminder to self to fix issues 114, 115: proposed 
            resolution -> description]

15:30 Naming issues
    - 114: Name of wsoap:fault/@name [43]
    - 126: Confusion between binding and element names [44]
    - Name attribute consistency
      [***** ACTION: Sanjiva to consistify the @name attributes. *****]
      Any issues here?

 [43] http://www.w3.org/2002/ws/desc/2/06/issues.html#x114
 [44] http://www.w3.org/2002/ws/desc/2/06/issues.html#x126

[pdowney: wants to make it editorial and move on!]
RESOLUTION: reassign 114 to part 3

Jonathan: Move on to: is Name attribute consistency an issue?
GlenD:    Open an new issue
Jonathan: Keep the action item for Sanjiva
ACTION:   GlenD and Sanjiva to come up with a proposal for the new 

[Sanjiva: If no resolution by next Thursday then we will close this 
          pending action item with no action.]

NEW ISSUE: check name attribute consistency

[dbooth:  One possible suggestion for GlenD and Sanjiva: append "Ref" 
          to names that are references.]

TOPIC: issue 126: Confusion between binding and element names 
Gudge, Sanjiva...: It's syntax error, not component.
DavidB:   Rename binding:operation to binding:operationRef
  1. don't do anything,
  2. rename binding operation
Two proposals for renaming: operationRef or bindingOperation
Straw poll:
  favor renaming? 7
  do nothing? 7
[Lack of consensus, no objections to keeping status quo.]
RESOLUTION: Close issue 126 with no action

16:05 Issue 131: Treatment of optional extensions [45]

 [45] http://www.w3.org/2002/ws/desc/2/06/issues.html#x139

[Umit:    1+ to Glen]
[Dbooth:  +1 to umit: "Who is doing the ignoring?"]
[DaveO:   This is why I brought up the issue with Glenn about 
          "who is ignoring".]
[Sanjiva: Proposed resolution: if an optional extension (i.e., 
          an extension not marked as required) is not understood 
          it MUST be ignored. Any not understood extension 
          attributes MUST be ignored. (Because there's no way to 
          mark attributes as required anyway)]
[Dbooth:  Furthermore, the service is obligated to support all 
          features stated in the WSD. ]
[Sanjiva: That is, the WSDL describes the service by definition.]
RESOLUTION: close issue 131 as proprosed and clarified above
ACTION:   Editors to add clarification for issue 131

16:20 Issue 139: Non-deterministic schema [46]

 [46] http://www.w3.org/2002/ws/desc/2/06/issues.html#x139

DavidB:   Propose to treat as editorial issue and let editors to 
          handle it.
Gudge:    My proposal in email is the only way to do it.
DavidO:   Schema wildcard should work, too.
Proposed resolution: Close issue 139 as Gudge proposed in issue list: 
          The only fix I can see given the current grammer is to 
          change the content model of wsdl:definitions to be 
          <xs:any namespace='##any' minOccurs='0' 
          maxOccurs='unbounded' />, which doesn't capture any of the 
          constraints regarding wsdl:include, wsdl:import, wsdl:types,
          but there you go! 
RESOLUTION: adopt Gudge proposal
ACTION:   Editors (namely Gudge and Roberto) to update the schema and 
          the spec accordingly.]
[DaveO:   I may object to the closure of issue 139, pending some 
          discussions I will have with Gudge.]

16:25 Issue 148: Double check URI comparison algorithm and relative 
               URI use [47]
      [***** Needs proposal, possibly based on TAG joint session ****]

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

Jonathan: Just sent a proposal about an hour ago.
[dbooth:  +1 to requiring all URIs that are used as identifiers be 
          absolute URIs.]
[umit:    +1 to Sanjiva]
[asir:    +1 to Sanjiva]
RESOLUTION: Change all URIs EXCEPT import/@location and 
            include/@location to absolute URIs at the XML document 
ACTION:   Editors to change spec to require absolute URIs and indicate 
          that comparison must be done character-by-character as per 
          TAG finding.
[jjm: maybe we can also lift the "Use of URI" section from SOAP 1.2:]
[jjm: http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#useofuris]

16:40 Issue 115: Improving on-the-wire conformance [48]
      STATUS: Resolution proposed at 19 Feb telcon.
      [***** Review actual text that gets added to the spec before 
             closing. *****]

 [48] http://www.w3.org/2002/ws/desc/2/06/issues.html#x115

Jonathan: Can not close. it's already on editor action list.
RESOLUTION: Schedule for resolution next week.

16:45 Issue 135: WSDL Specification readability [49]
      [***** STATUS: David Orchard to produces a specific example of 
             the kind of change he envisions. *****]

 [49] http://www.w3.org/2002/ws/desc/2/06/issues.html#x135

Jonathan: Need proposal for example changes.  Plan to produce last 
          call with resolutions from this F2F incorporated. Can not 
          wait until May F2F.  In light of that, if we don't see 
          example by thursday, will be left out last call
RESOLUTION: schedule for resolution next week based on proposed examples

16:50  Issue 104 Appendix E cleanup (using alternate type systems) [50,
     - Bijan's review [52].
     - Might want to add OWL support to appendix E
      [***** STATUS: Awaiting concrete proposal from Jacek and 
             Bijan (does 143, 144, 145 cover it?) *****]

[50] http://www.w3.org/2002/ws/desc/2/06/issues.html#x104
[51] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0136.html
[52] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0182.html

[Sanjiva: closed with no action as subsumed by other issues]
RESOLUTION: close issue, covered by other issues.

16:55 Issue 97: Schema language for SOAP encoding [53]
    - Proposal from Jacek [54]
    - Address comments from reviewers (Paul, Asir)
    - Decide on disposition: Chair recommends a Note.
      [*****ACTION:   Paul and Asir to review the SOAP Data Model 
                      Schema. *****] 

 [53] http://www.w3.org/2002/ws/desc/2/06/issues.html#x97

ACTION:   Asir will send comments to list.
RESOLUTION: reassign issue to part 3.

17:00 Issue 106: Using RDF in WSDL [55, 56].
      [***** STATUS: Dependent upon RDF mapping first draft, need to 
             figure out how to get unblocked from going to Last 
             Call. *****]

 [55] http://www.w3.org/2002/ws/desc/2/06/issues.html#x106
 [56] http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0076.html

RESOLUTION: reassign 106 to RDF mapping

17:02 Issue 111: Simplified syntax?  [57]

 [57] http://www.w3.org/2002/ws/desc/2/06/issues.html#x111

RESOLUTION: Close issue 111 with no action
[dbooth:  Reason for closing issue 111: Given that nobody has changed
          their mind about wanting this, DaveO has withdrawn his 

17:05 Next steps towards Last Call
    - How to close any unresolved issues.
    - When will we see the first internal Last Call spec?
    - Process for reviewing and approving Parts 1 and 2.
    - Ramping up on Part 3.

Jonathan: Schedule telcon for next Thursday to close more issues.
          Two weeks from Thursday, see a draft with resolutions 
          incorporated.  From now, move bar higher for adding 
          issues to part 1 and part 2.  Criteria for new issues 
          for part 1 & 2 : must be accompanied by a concrete 
          proposal.  Once we hit the 0 bug bounce for part 3, we 
          will revisit remaining/new issues for part 1 & 2

Umit:     What to do with media type document?
Jonathan: We have a proposal but haven't adopted by the group so 
          far. We can do it now, or ...  Two parts of that, one 
          in instance, one in schema.  How do we adopt it as a 
          wg deliverable?
Umit:     Assign action item with date
Anish:    XOP has dependency on this. Schema part belongs to WSD 
          WG. Instance part can go either way.  But instance part 
          is related/dependent on schema part.
Jonathan: How will we get this into our process?  Suggest adopting 
          as a note.
Sanjiva:  We may need to involve schema group.
Jonathan: Not yet.
Sanjiva:  Worry about time line.
Jonathan: This is something we removed from WSDL1.1
[DaveO: Why a Note?]
RESOLUTION: Adopt Umit proposal as a base for a note on representing 
            media types in schema.
Anish:    Anything to report to XMLP WG?
Jonathan: Will send a note to them, asking them for volunteering 
ACTION:   Jonathan to send a note to XMLP, asking them for 
          volunteers for editors.
[JacekK: DaveO, what else?]
RESOLUTION: Umit appointed as WSD WG Editor on note.
ACTION:   Editors of media type proposal to give Jonathan a list of 
          open issues.

Jonathan: HTTP binding issue planed for next Thursday call
Hugo:     Request to move http binding for week after next week

Sanjiva:  Is concerned about the status of the RDF mapping of WSDL.
Jonathan: Nice to have a working draft.  If not already done so, I
          appoint Bijan as editor of RDF mapping.
[pdowney: has a stong interest in the RDF mapping: it assists formal 
          testing of processors, decentralised discovery, and 
          composition of legacy Web services ]
RESOLUTION: Bijan appointed as RDF Mapping editor.

Jonathan: If no request from people, and if nothing for agenda next 
          on, will randomly select part 3 issues to put in agenda.

18:00 Adjourn
Received on Tuesday, 9 March 2004 11:41:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:47 UTC