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

Minutes, 23 Sept 2003 WS Desc WG FTF

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Mon, 29 Sep 2003 17:09:27 -0700
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA2014607B4@RED-MSG-30.redmond.corp.microsoft.com>
To: <www-ws-desc@w3.org>

Web Service Description Group
Minutes, FTF meeting 22-24 Sept 2003
Palo Alto, hosted by SAP.

Tuesday 23 September

 David Booth            W3C
 Allen Brookes          Rogue Wave Software
 Roberto Chinnici       Sun Microsystems
 Glen Daniels           Sonic Software
 Paul Downey            British Telecommunications
 Steve Graham           Global Grid Forum
 Tom Jordahl            Macromedia
 Jacek Kopecky          Systinet
 Philippe Le Hégaret    W3C
 Kevin Canyang Liu      SAP
 Lily Liu               webMethods
 Jonathan Marsh         Chair (Microsoft)
 Jeff Mischkinsky       Oracle
 Bijan Parsia           University of Maryland MIND Lab
 Arthur Ryman           IBM
 Jeffrey Schlimmer      Microsoft
 Steve Tuecke           Global Grid Forum
 William Vambenepe      Hewlett-Packard
 Sanjiva Weerawarana    IBM
 Umit Yalcinalp         Oracle
 Prasad Yendluri        webMethods, Inc.

 Amelia Lewis           TIBCO
 Jean-Jacques Moreau    Canon

 David Orchard          BEA

 Youenn Fablet          Canon
 Steve Lind             AT&T
 Ingo Melzer            DaimlerChrysler
 Adi Sakala             IONA Technologies

Agenda [0]

[0] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0140.html

Scribe: William Vambenepe

09:00 WSDL - 1.2 or 2.0?

Discussion on whether to name our work wsdl 1.2 or 2.0
Jonathan:  At the end it is probably going to be a director discussion,
           but we can express our opinion.
Proposals: wdl, wsdl ii, wsdl 1.2.0, wsdl 2, wsdl the sequel... ;-0
Jonathan:  Have heard requet for 2.0, not much for 1.2, but some people 
           want wsdl 1.2 to be aligned with soap 1.2.
dbooth:    We've specifically paid attention to soap 1.2 in this group
Jonathan:  Does anyone object to naming our version 2.0?
Sanjiva:   Wsdl 1.0 was created for soap 1.1, wsdl 1.1 was created later.
sgg:       Numering schemes don't really matter much.
Roberto:   New version of wsdl is not backward compatible with 1.1.
[plh-lap:  sgg: http/1.1, soap 1.2, and wsdl 2.0]
Jonathan:  No objection heard to recommending 2.0.
ACTION:    Philippe to recommend the wsdl 2.0 name to Director.

09:20 R085 Describing endpoint references.  [30]
   - General agreement to add such capability to WSDL, but
     not agreement on the precise form of the annotations and
     where in the WSDL they should reside. Proposal
     from Umit [31], response from Arthur [32].
   - Related issue (?) dynamic discovery of a service [33].
   - Arthur to work with Umit to unify approaches.

 [32] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jun/0142.html
 [33] http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0004.html

[jeffm: I just mailed a zip file with html for the presentation]
[dbooth: Arthur's presentation: http://lists.w3.org/Archives/Public/www-archive/2003Sep/att-0064/ws-ref-present-0.9.html]
[plh-lap: (Arthur's presentation is also at http://www.w3.org/2003/09/ws-ref-present-0.9.html )]

Arthur:   Arthur and umit have a joint proposal, jeff to email the slides 
          to the list.  Problem statement: we want to be able to send 
          messages that contain reference to services. Question of
          whether the service reference is self-describing or not. Need 
          to specify both type info and instance info. What info do you 
          know at design time? 3 cases:
            1- interface and binding
            2- interface only
            3- no type info known
          Introduce a new element in wsdl called "reference". Interface-
          related ref info specified at interface layer.  Binding-related 
          ref info specified at binding layer. In the simplest case 
          (interface and binding known at design time and only a URL 
          needed at runtime) then all we need to send is a URI. In all 
          other cases, we have defined a ws:Service. One could use other 
          reference mechanisms, such as ws-addressing.
[Arthur shows an example.]
Arthur:   In the example, manager and engineer have differnet interfaces.
          Introduce a manager reference (a URI) and an engineer reference 
          (another URI) to tag. The department type has a manager element 
          of type managerReference and an engineer element of type
          engineerReference. In the operation output, there is a 
          wsdl:reference element to say that any type that is a managerType 
          points to a manager interface.  And vice-versa for engineer. This
          association could go in the schema but then the type is not as 
          reusable and we reach to wsdl in schema. which is why we decided 
          to not do it this way.
Glen:     Defends using schema for this.
Roberto:  Code written to handle an engineer type won't know that this URI 
          is associated to a web service reference if this association is
          not in the schema.  So it will treat it as anyURI and won't know 
          that it can invoke web services operations on it.
Arthur:   Another wsdl:reference element in binding/operation to associate 
          the ManagerReference type to the ManagerBinding.
[end of the first example.]
Arthur:   Second example: you only know the interface at design time.
          In the soap message, you don't have just a URI, you have a 
          complex type that tells what the binding name is in the wsdl, 
          we are creating a ManagerReference type that extends wsdl:Service
          (instead of anyURI in the previous example). (In the soap message 
          you also get the endpoint address since it extends wsdl:service.)
          Since the binding element is reference at runtime, we no longer 
          have the binding association in the wsdl binding.
Roberto:  Couldn't you get a similar result without using a reference by 
          using the schema?
Arthur:   Yes but instead of an extension you need to do a restriction 
          and repeat the whole service type (and set the interface to a 
          fixed value.) Also, how would this work for other types like 
          ws-addressing?  So we chose to declare it in the interface.
[end of 2nd example, start of 3rd example.]
Arthur:   At design time yo know neither the interface nor the binding
          message looks the same as in example 2.  (note: the soap message 
          also has a wsdlDescriptionLocation attribute as a hint to be able 
          to resolve the QName used to represent the hr:Manager.)
Glen:     Why not do this at the service level (instead of the department
Umit:     Actually, this was in the proposal (disconnect between the 
          example and the proposal).
Glen:     Proposes a better breakdown of the wsdl:service type where there
          is a common type that is derived by both the type used in the 
          wsdl doc and the type used in this proposal (instead of making 
          it a restricion of the wsdl service element.)
Tom:      The only reason to specify the interface in your wsdl is for 
          validation ?
Arthur, jJacek: Also to allow your tools to generate smarter code.
DaveO:    You are now mixing thhings from the wsdl namespace into the 
          runtime message. is this a pb?
Arthur, umit: why is this a pb?
DaveO:    There has been pushback on this in the past.
[The group doesn't seem to see a concern with that.]
DaveO:    I think it is a good thing personally for wsdl to provide that,
          but i have heard pushback on this
Dbooth:   I don't have a concern with the use of the wsdl namespace in 
          message. I just have a concern with the complexity.
[For @type, @interface, @binding the level nesting defines the scope of applicability, with lower-level overwriting.]
Sanjiva:  Not consistent with what we do in binding.
Arthur:   Whatever we do we want to do it in a way consistent with the 
          rest of the wsdl spec.
WilliamV: Because our extensibility is ##other, the descriptionLocation
          would have to be defined in another namespace, not the base 
          wsdl namespace.
Arthur:   This descriptionLocation attribute can be used anywhere, not 
          just in this proposal.
Jonathan: Why not use an import instead of descriptionLocation?
Arthur:   We could, but import has additional semantic
Sanjiva:  This is just a small piece and independent from the main 
          proposal, let's not spend time on descriptionLocation now
Jeffsch:  Jonathan was making an analogy between sending a message with a 
          wsdl:service and sending the wsdl doc. i'd like to understand 
          why this propsal doesn't do that (send wsdl doc directly).
Arthur:   In the 3rd case it's possible to do it this way.
Jeffsch:  Then are you assuming that the 2nd case is most common? Sending 
          the whole wsdl would not be bad for case 3.  Trying to understand 
          the value we get from generalizing a wsdl construct to allow new 
          usage of it.
Sanjiva:  The proposal doesn't prevent sending the whole wsdl doc since 
          you can extend any type you want.  The reference element in the 
          operation tells you which type in the message is mapped to an 
          interface.  This approach doesn't say what the type has to be. 
          It can be a URI, a wsdl:service or anything else.
Arthur:   We (umit, glen, arthur) have done what this WG asked us to do.
          If people don't like the design they should have joined us, 
          this was open to everyone and advertised.  We can't do design 
          on the fly at the board. If we think it's a good direction let's 
          accept it and we can improve the design later.

10:30 Break
10:50 Endpoint references (cont.)

Jonathan: We don't have to solve all the issues on this proposal. What 
          we need is to decide whether we want to add some sort of 
          endpoint refence to our spec.
  1 - should we add the concept
  2 - if yes at the wsdl level or the schema level
sgg:      This is a requirement, so if we answer no to -1- we need to 
          remove it.
Jonathan: It is a SHOULD requirement.
Tom:      I think the proposal is not too terrifying but the concept of 
          endpoint reference is not necessary in wsdl 2.0.  This is not 
          in wsdl1.1 and we don't need it in wsdl2.0. What we need is 
          bindings and faults and other things we haven't talked about 
          yet, and we should focus on the basic parts of the spec.
dbooth:   Same concern as tom.  This is adding complexity to the language 
          beyond what is needed for us to declare success. There are 
          reasonable application-level workarounds that make this not 
Jeffm:    The ability to do callback is missing. we can't do this without 
          service reference.  This is a very important need, there is no 
          way to do that right now. it is a fundamental missing piece to 
          web services. It is not good to have this done in app-level, in 
          ways that differ for each vendor.
Roberto:  Not having nightmares about this proposal but it looks 
          complicated. But I agree with jeffm that we can't leave this at 
          the app level. But I'd like the solution to be minimal.  If we 
          can use service as a glorified URI then this might be enough 
          and we don't need to overdesign or provide wide 
          extensibility points. Just offer one standardized way to do it 
          that works for 80% of the cases.
DaveO:    I like the idea of this proposal. I like the idea of moving 
          wsdl cosntructs into the message and this is the right group to 
          do it.  There is possiblity of simplification of this proposal.
Jacek:    Support this proposal. simple and useful.
Arthur:   This proposal is the analog of hyperlinking
Strawpoll: in favor of adding service ref 16, against 2
Amy:      In favor of the concept but this proposal might be slightly 
Jonathan: Are any of those against strongly opposed to it.
Tom:      Do we really have to do that?  There is a lot of work left if 
          we do that.
Glen:     There is a proposal that has a few issues identified already, 
          none of which seems to hard to solve.
Kevin:    If we have enough resources to work on this and it doesn't 
          affect the timeline then I'm for it.
Jonathan: Any additonal work has an impact on our timeline.  Any objections
          to recording the consensus of the group to add service reference?
[no objection]
Jonathan: I propose that we accept the proposal and spend the next 30 
          minutes to enumerate the issues we have
Roberto:  The 5 cases that look similar in this proposal are actually not 
          that similar. We need to decide what kind of service reference 
          we want in the space. We don't need to have any type be 
          potentially used as a reference
Sanjiva:  We can't bless ws-addressing in this group but i won't agree to 
          a way to do service reference that precludes people from using 
Roberto:  The app needs to do 2 things: decide what type to use to pass 
          reference info AND let the other end know that this type
          represents a reference.  The 2 things are independent and we 
          don't have to do both. the pb should be split.
Sanjiva:  The fact that there is a reference and identifying specific 
          types cannot be separated.
Glen:     What people want is when they receive an XML that contains a
          reference what their toolkit gives them is not an object that 
          represents the piece of XML but an actual stub to this 
Roberto:  Yes, but the knowledge that soemthing is a reference is 
          useful only if you understand how to use it. so I agree with 
          your use case but you can do that by definig a specific type 
          to use as reference.
Sanjiva:  And at this point you don't need to put anything into the wsdl.
Dbooth:   Wxactly what interop is gained?
Roberto:  I am in favor of describing in this group one particular type 
          for reference for itnerop.
Glen:     And then there is no need to have a generic "this is a reference"
          marker because you understand the semantic of the reference type.
          (Either the one we define or the one someone else defines, like 
          ws-addressing endpointReference.)
Dbooth:   You already need out-of-band info when you interpret a wsdl, 
          for the semantic of the operations. This is just another part of 
          this mechanism and can be done out of band too.
?:        Do we need to step back from the proposal, develop requirements 
          and then revisit the proposal?
Jonathan, jeffm: that sounds like a long way around.
Glen:     Let's have an issue on the proposal that it is too monolothic 
          and needs to be broken into pieces.  There are really 3 parts 
          to this proposal.
Lily:     I agree with roberto, i am not comfortable to being to tag 
          just about anything.
[jeffsch: Paraphrasing Glen/Roberto, there are three requirements: way to associate a type with a reference, way to serialize a reference, way to indicate where to retrieve a description.]
Arthur:   Rather than general objections, why don't people come up with 
Roberto:  I trust that your design works, the question is about the 
Glen:     The initial requirement is too general.
jeffsch:  Roberto, can you identify which ones of the subrequirements 
          don't need to be addressed?.  Same question to tom.
[3 requirements are:
  1) ability o arbitrarily label a type as a reference
  2) defining of a single serialization as a resference that is 
     normativaly in the spec.
  3) ability to have the wsdl location attribute provided with 
     clear semantic so that everywhere you use a wsdl qname you can 
     specify where the wsdl is where this qname is defined
(cleaning up the 3rd req to make it sound more like a requirement and less like a solution, suppress mention of an attribute, it could be any mechanism)

[jeffsch:  R085: The description language SHOULD allow describing 
           Messages that include references (URIs) to typed referents, 
           both values and WSDLServices. (From PP. Last discussed 11 
           April, 2002.)]
Umit:      The reference to any type or a specific type is a sub-issue, 
           the requirement is the ability to point to something that is 
           an implementation of a specific interface.
[jeffsch:  R131: The WG SHOULD define components that may be used within 
           Messages to refer to other WSDL components. (From DO. See 
           also R085 and R120. Last discussed 6 Feb 2003.)]
correction of the 1st requirement:
[dbooth:   1. Add the ability to associate an interface type and-or 
              binding with a service reference / URI
           2. Define a reference serialization.
           3. Ability to refer to the source of wsdl constructs used in 
              a message.
           3. Add the ability to refer to location of a WSD.]
Jonathan:  How do we move forward on this?
Jeffm:     I am tired of "let's all go back and agree on requirements". 
           I would rather agree on concrete proposals.
Roberto:   We have made progress in understand R0085. we have now managed 
           to break it down in 3.
ACTION: roberto, glen: provide a counterproposal to the current proposal.

Jonathan:  Do we agree to take the current proposal as status-quo
Roberto, tom: No
[DaveO:    I also think we understand R131 better as well...]
[Roberto:  yes, R131 makes more sense now]
Jeffm:     Propose that we direct the editors to put the current proposal 
           into the document.
in favor: 11, opposed: 4
Jonathan:  do we have consensus?
Roberto:   no
Glen:      Other proposal: the editors put in the spec the part about 
           just adding service reference at runtime
Kevin:     If we think the new proposal (that roberto and glen signed up 
           for) will be better, why give our editors extra work that 
           won't be needed?
Sanjiva:   This has been on our task list for a very long time.
[jeffsch:  Shall I add the requirements 1, 2, 3 above to the requirements 
           DR134: [Draft] The description language SHOULD allow
                  associating an Interface and/or an InterfaceBinding 
                  with a WSDLService reference and/or URI. (From WG 
                  discussion. Last discussed 23 Sep 2003.)
           DR135: [Draft] The description language SHOULD define how to 
                  serialize a WSDLService reference. (From WG discussion.
                  Last discussed 23 Sep 2003.)
           DR136: [Draft] The description language SHOULD define a means 
                  to refer to the location of a Web service description.
                  (From WG discussion. Last discussed 23 Sep 2003.)]
DaveO:     People love the idea but the mechanics are not agreed on. 
           Roberto was voting against including it in the doc because it 
           would weight this proposal too much. I voted for including it 
           even though there might be large changes to it but it puts 
           pen to paper on it.
Roberto:   But putting this in the doc is implicitly accepting the first 
           requirements. And it would be hard to take it out.
Glen:      I don't think that putting it in the spec really means we 
           accept a requirements. So it would be ok to accept this 
           proposal as is.
Sanjiva:   I find unacceptable a proposal that says "you can only use a
           certain type as a service reference".
Glen, roberto: You can use oher ways to do reference if you want, like 
Sanjiva:   But wsdl won't support it.  The type itself is not enough, 
           you need additional info in the wsdl.  What magic does axis 
           use to know whether to deserialize the reference element into 
           a stub or into a DOM object?
[dbooth:   I've heard the WG affirm its desire for endpoint references. A 
           TF drafted a proposal, and brought it to the WG. The WG has 
           affirmed its desire for endpoint reference. A task force made 
           a proposal. the WG is debatting technical reserve with this
           proposal. Those who most oppose it have volunteered to write 
           a counter-proposal. Why not let them do that?  I'm hearing the 
           WG debating significant technical issues with this proposal. 
           I'm also hearing the people who have voiced the main concerns 
           with the proposal expressing the willingness to draft a 
           revised proposal. Why not let them do it?]
Jonathan:  But the counter-proposal would not include parts that are 
           necessary for others to accept it?  Maybe we need to wait 
           until we have another proposal.  Let's have off-line 
           discussions over lunch between interested parties and get 
           back to it tomorrow morning.
Jeffsch:   Do we want to add the requirements to the requirement doc?
Jonathan:  Not sure we need to do this at that point.
Glen:      They are fine requirments to accept.
Roberto:   Can we add "in a message" at the end of 136?
[jeffsch:  DR136: The description language SHOULD define a means to 
           interpret QNames from outside the context of a Web 
           service description.]
RESOLVED:  No opposition to accepting these requirements.

12:00 Lunch
scribe: Philippe

13:00 Attributes
  - TF revised proposal [34]

 [34] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0185.html

Attributes - TF revised proposal and presentation: 
[dbooth: Steve's presentation converted to HTML: http://lists.w3.org/Archives/Public/www-archive/2003Sep/att-0065/Report_from_the_ATF_4_clean.htm]

[Steve runs the show]
slide - "What is an Attribute"
slide - "What is needed?"
slide - "Why is this Needed?"
slide - "ATF proposal"
slide - "As with last time, Define Attribute Component on the Interface"
slide - "Bindings define how to do simple get/set on the attribute's value"
slide - "SOAP/HTTP binding"
slide - "SOAP/HTTP binding" (set request)
slide - "HTTP binding"
Steve:    Modulo the notion of the set not returning, the report is 
          similar to the presentation.
Tom:      Looks like a requirement to me.  You need at least the 
          attribute doesn't exist response.
Kevin:    set/get for one attribute only?
Steve:    Correct. Coing more than one attribute at a time will be done 
          in another spec.
SteveT:   Also query capabilities, aggregation of attributes, ... let's 
          just introduce the basic need here.
Steve:    Also timing requirement, ...
David:    Do you see a need for a bulk load capability to make realistic 
Steve:    In certain case yes. The proposal does not preclude a getX/setX 
Roberto:  Now that we have a style on operation, we can turn attributes 
          into syntactic sugar with attribute set/get style, so we won't
          have at the component level.
Steve:    How difficult would it be to derive the attribute set?
Roberto:  You can find this at the operation with "attribute" style.
Steve:    And if we want to do extension, how would you do it?
Roberto:  You can say all extensions that are on an attribute are 
          reflected in the model.
Steve:    So we would put that style in WSDL?
Roberto:  Yes.
Steve:    With a style URI and well-defined semantic
David:    So, to some extenT, it would be a sub-style of RPC?
Roberto:  Yes. Two operations (one for set, one for get). (same idea as 
          Java bean properties.)
Tom:      It wouldn't be like the RPC style, since RPC is only a hint.
JeffS:    The variation being discussed would also be a hint.
Glenn:    Not only a hint, the variation constraints the binding, if you 
          ignore it, you can't get/set the attribute.
Tom:      So Roberto suggests setX/getX with appropriate style attribute?
JeffS:    The binding binds the component model, not the syntax.
Tom:      So, it's a macro. attribute foo > "xslt transform" into get/set 
          foo, with a style attribute. Why would you need the style then?
Roberto:  The attribute declaration, or the style on the operation 
[ie. Roberto agrees with a syntax, but we map it to the operation component model]
Glen:     Mapped into a get in a particular namespace?
JeffS:    Not sure yet.  You can use the style to determine attributes, 
          you don't need to constrain the names.  Duplicates will be 
          detected the same way we detect duplicates operations today.
David:    If it is only syntactic sugar, is it needed? Might get complex 
          if it is not a syntactic sugar in fact
Jonathan: If it is only syntactic, how does it interoperate with others,
          such as properties and features?
Tom:      Still wondering if we really need attributes in WSDL... today, 
          I'm inclined to accept the proposal :-). But I'm still interested 
          in discussing this aspect
William:  For management, we need attributes but don't care about the 
steve:    Differences come in when you work on subsets of attributes, 
          query, ...
Jacek:    With RPC, we're introducing the concept of functions/parameters.
          With this proposal, we would introduce the concept of attributes.
          I don't see any kind of barrier against it.
Roberto:  If possible, we should address attributes. otherwise our tools 
          won't understand grid extensions.
Kevin:    Seems like attributes are special kind of operations. What kind 
          of visibility do you have? Can operations manipulate attributes?
Steve:    How it is implemented is not dependent on this proposal.
Jeffs:    So I can have an attribute count and an operation increment 
          { count++ }
Steve:    I don't think that we should preclude that.
Kevin:    Slide 8. What does the wsdl binding definition for the attribute 
          look like?
Steve:    There will no wsdl binding defintions.  It will force the 
          endpoint to accept and response with pre-determined messages.
JeffM:    So, following my earlier point, at some level you don't need 
          this. I can see that communities need this. but I don't think 
          that we should change the component level for that. I don't 
          like adding the special messages. You would need rules to avoid 
Prasad:   So, this is a shortcut for set/get operations. with additional 
David:    If we take the approach of defining a new style uri, without 
          adding new syntax, that would be enough.
Steve:    It's more convenient for tools to think in terms of attributes,
          instead of digging the style attributes.
[dbooth:  If we do this with a style URI, then you could automatically get
          a bulk load facility.]
Steve:    Tools we'll look at the component level, not the syntax. It's 
          more awkward.
Sanjiva:  If we accept the proposal as a shortcut syntax, you'll have no 
Jacek:    I don't like duplicate syntax
[alewis:  TIBCO Software, Inc., is willing to accept either 
          resolution of this issue. Developers polled did not feel strongly,
          and I have heard no compelling further arguments in 
          either direction today. So we're a strong, pronounced,
Roberto:  Having a first class attribute notation still leave a place 
          where you can put extensions for them.
SteveT:   (to Jeffs) if your tool/object representation, I wouldn't see 
          the attributes? only the get/set operations? Seems like we have 
          the syntactic sugar extension with the style thing, it doesn't 
          seem necessary to me.
Sanjiva:  In wasl4j, the attributes will end up in the component model, 
          not the syntax.
Steve:    So, OGSI have a findServiceData, that returns a structure full 
          of attributes. We didn't see a need to introduce a grouping 
Tom:      The more I hear about modyfying the component model, the more I 
          don't like it. I like the original proposal from Steve.
David:    If you follow the approach of the style attribute, it is similar 
          to RPC.
Glen:     It seems important to address this subset, but the proposal is
          being diluted. maybe you'll be better off as an extension. I'd
          love to see that as an extension, with query mechanisms, etc.
          I'm ok with putting the diluted approach, but you should 
          provide extensions.
[TomJ:    I propose to just adopt a new style hint for properties, and 
          not use an attribute element at all either as a first class
          element or as syntactic sugar.  This would require the WSDL 
          author to define all the get/set operations, and label them 
          with the style. which is what we are proposing to do with the 
          attribute element which is just a shortcut.]
Steve:    If I have a1, a2, and a3. I have access restriction. 
          BulkQuery(a, a2) (with <> access rghts on a1 and a2) will work?
Jacek:    I believe so.
David:    So we have
[dbooth:  Straw poll:]
[dbooth:  Option 0: Do nothing.]
[dbooth:  Option 1: Define two operation styles (get & set), analogous 
                    to RPC, that (if used) asserts that elements of the 
                    operation conform to particular conventions.]
[dbooth:  Option 2: Option 1 plus: Adopt syntactic sugar for attributes, 
                    that would map to get/set operation styles.]
[dbooth:  Option 3: Adopt attribute syntax and add it to the component 
William:  clarification of option 1. we would create a URI, and an
          associated semantic?
Umit:     Option 5 - we can add an other style, that is called attribute 
          to the operation (similar to option 2) but doesn't ditacte [...]
straw poll
option 0: 2
option 1: 4
option 2: 8
option 3: 2
Kevin:    We objected for RPC, but not for attribute.
Steve:    <interface ...><attribute elt=Qname attrstyle='anyURI' ... ?
Jacek:    I'm completely against this. If you don't understand the URI, 
          you can't ignore it.  You would not obtain the same components.
[Roberto: +1]
Steve:    If we add "none" on the access attr of the attribute 
          construction, that would allow me to extend the model.

15:00 Break
15:20 Attributes (cont.)

Jonathan: So?  Should we redo the straw poll to see where we are?
Straw poll on just option 1 and option 2
 option 1: 7
 option 2: 8
New straw poll: which one do you really hate?
 option 1: 0
 option 2: 0
Jacek:    We seem to have consensus that we do want to represent 
          attributes using operation style. We can work on those style, 
          and then we can accept the style and vote on the syntactic sugar
          (we would still need the mapping between syntactic sugar and 
Bijan:    Introducing lots of stuffs for not getting the desire effect.
Jonathan: Would it be acceptable to have style uri but not syntactic
Steve:    If we just take option 1, there is nothing stopping us to 
          define syntactic sugar. But at least, we'll have a place in 
          the component model.
Jacek:    More than syntactic sugar, it will be an extension.
Glen:     Attributes will happen. Management and grid want them. They're 
          going to do "in the cool way", using extensions.
[some discussions between William and Glen about WS management]
William:  Management would like to use a common channel and access 
          existing tools.
Glen:     Similar to the Javabean pattern.
Bijan:    So why not option 4? why are we in the middle?
Glen:     Option 4 is expensive. 2/3 are adding metadata on operations.
          The syntactic sugar introduces more complexity in the wsdl 
William:  The extra work seems reasonable.
Jonathan: Having 2 ways to do the same thing is sub-optimal.  So, we 
          need to work on a proposal to address option 1 at least.
Glen:     Let's make a decision and work on the details.
Sanjiva:  We can defer decision on option 2 later.
Wteve:    The tf introduced a new component
Jonathan: So consensus is style uri and ask the editorial team to write 
          a spec?
Tom:      I don't like it but not sure it's helpful. I'd rather have 
          option 3.
Joanthan: Syntactic sugar and having a component are quite incompatible.
Glen:     How many people are in favor of doing something instead of
          nothing? i.e. can we drop option 0?
Tom:      I like option 3 or option 0.
CONSENSUS: we'll do at least option 1
ACTION:   ATF to describe for these style uri for attributes
ACTION:   Core editors to include those rules in the draft

Roberto:  The rules for the style are more complicated than the syntactic
Glen:     You need at least to name the operations.
Jonathan: Objection to adopt a syntactic sugar (option 2)?
for: 9, against: 5
David:    If we do that, then why not for RPC as well?
Jacek:    The tools will need to understand option 1, adopting syntactic 
          sugar will make the life of tools harder, eaiser for humans. We
          are alluding the existence of the component model if we are 
          introducing syntactic sugar.
Umit:     I'm unconfortable if we don't have a syntactic sugar proposal.
Roberto:  You'll have a separate section for xml representation of 
          attribute if we have syntactic sugar.
[pauld:   Orthogonality seems important to me.]
Bijan:    what is the motivation for syntatic sugar over component?
Jeffs:    Every binding will need to accomodate this as well.
[pauld:   Are attributes going to be more widely used than rpc bindings 
          and human encoded so deserve more assistance ?]
David:    It would be easier for people who are writing the wsdl. For 
          tool-generated wsdl, it won't make a difference.  For wsdl
          processors, they'll have to recognize the syntactic. If we 
          don't, you'll have the option to ignore that style.
Roberto:  You can ignore the style anyway.
[Roberto: You can blindly map the syntactic sugar to the right 
          component model and still ignore this particular style.]
Jacek:    I'm considering objecting to the syntactic sugar now.
Jonathan: So do we want option 2?
Jacek:    Let's defer the actual judgement.

17:30 Adjourn
Received on Monday, 29 September 2003 20:09:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:26 GMT