- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Mon, 29 Sep 2003 17:09:27 -0700
- 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
-------------------------------------------------------
Present:
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.
Phone:
Amelia Lewis TIBCO
Jean-Jacques Moreau Canon
Observers:
David Orchard BEA
Regrets:
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.
[30]
http://lists.w3.org/Archives/Public/www-ws-desc/2003Apr/att-0088/R085-20
03-04-22.html
[31]
http://lists.w3.org/Archives/Public/www-ws-desc/2003Jun/att-0024/umit_pr
oposal.html__charset_ISO-8859-1
[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
level)?
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.
Sanjiva:
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
required.
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
overcomplicated.
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
ws-addressing
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
reference.
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
counterproposals?
Roberto: I trust that your design works, the question is about the
requirements.
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
doc?
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
ws-addressing.
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:
http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0186.html
[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
use?
Steve: In certain case yes. The proposal does not preclude a getX/setX
methods.
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
component
[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
state.
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
duplicates.
Prasad: So, this is a shortcut for set/get operations. with additional
constraints?
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
choice.
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,
"whatever".]
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
mechanism.
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
model.]
William: clarification of option 1. we would create a URI, and an
associated semantic?
[Yes]
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
operations.)
Bijan: Introducing lots of stuffs for not getting the desire effect.
Jonathan: Would it be acceptable to have style uri but not syntactic
sugar?
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
processor.
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
sugar.
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 UTC