- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Wed, 6 Aug 2003 10:15:55 -0700
- To: <www-ws-desc@w3.org>
-------------------------------------------------------
Friday 1 August
-------------------------------------------------------
Scribe: Arthur
09:15 Attributes Task Force Proposal [1]
[1] http://lists.w3.org/Archives/Public/www-ws-desc/2003Aug/0000.html
Arthur: Why doesn't <attribute> have a @name attribute for
name-value pair semantics?
SteveG: A name is not needed since the element name serves that
purpose.
Robert: Agree with Arthur.
Umit: We didn't see any use for the name.
William: This issue will get clearer in later in the presentation.
Presentation continues...
SteveG: Binding defines how attributes are mapped to operations.
Mapping is defined by a URI.
Jonathan: So you only have interop if you understand the URI.
SteveG: We recommend defining three standard binding style URIs:
1) Untyped get/set,
2) OGSI Expression-based (XPath),
3) CORBA IDL strongly typed getXXX/setXXX
SteveG: One or more styles can be provided.
Presentation completed. Discussion follows.
Jonathan: Your claim that this proposal promotes interop is
contradicted by the flexibility in binding styles.
SteveG: But WSDL has pluggable <binding>s too.
Hao: Attributes are state and WSDL can already support service
state.
Glen: WSDL is extensible. So why not make this an extension that
some other group can standardize. The attribute proposal
should be standardized by the community of users who want it.
This WG should only standardize the core function and enable
extensions. For example, security is more widely needed
than attritubes but security is not core.
Umit: Security is not a good analogy. Attributes are of interest
for managability. Attributes are more core. Several different
commnities want it so we should standardize it.
Glen: This proposal implies all WSDL implementors need to support
it.
William: Only if you create service.
Arthur: If this is a standard part of WSDL then tools to create client
proxies will have to support it.
Tom: I'm firmly opposed.
1) Implicit operations give me the "heeby geebies".
2) This is a very advanced feature, too ambitious for WSDL 1.2.
3) It is too complex to support for implementors.
Roberto: I'm perplexed. You can specify binding style on a per
attribute
basis. For example, Grid services will use OGSI style. Others
will use different style. At the interface level attributes
are just data packets. Other behavior, e.g. query, is beyond
interface. WSDL should be confined to interface level. We
should clean up the interface. Attributes complicates it.
Different communities will define different style of
attributes,
so we not just put these in mix-in interfaces. e.g. WSDM
get/set,
or Grid can define mix in interfaces. Why wouldn't that work?
SteveG: It wouldn't be standard.
JeffS: Roberto, please clarify your alternative.
Roberto: Each community defines an interface, e.g. WSDM get/set.
Glen: For example, the credit card validation industry could
implement
a standard interface.
JeffM: What would a WSDL processor be required to implement?
SteveG: We haven't nailed that down yet.
Umit: We would have to standard some styles and processors would
have
to support them.
JeffS: What about the MEPs and Bindings? A compliant processor would
have to support all standard MEPs, Bindings, Styles, etc.
Jonathan: The WSDL spec doesn't state what a WSDL processor must
support.
Tom: There is a lot of work both on the client and the server to
support this.
Glen: This is more than WSDL. This is an architectural issue. There
should be a WS-State WG.
William: HP recently released a Management spec that specifed several
attributes. Specifying attributes in WSDL is useful.
Roberto: The semantics of the attributes are specific to the community.
Sanjiva: I agree with the concern on the lack of a standard access
mechanism for attributes since that reduces interop. You are
forced to look at the binding. We no longer have normal
operations. We have message exchanges. You could say an
attribute is syntactic sugar for a specific message exchange
pattern. Input message element QNames must be unique.
Therefore
you don't need to generate methods on the server for each
attribute. You could have a single method on the server to
handle attributes. We could eliminate the styles and just have
a simple way to handle the attribute messages.
Glen: The real question is: Should we be doing this?
Umit: We need to agree on what WSDL should include. I'm not clear on
this.
Glen: We have a Requirements document and now an Architecture for
Web services. That defines the scope of WSDL. We also need to
be extensible so other communites can add function. We have
wsdl:required, and have have pluggable type systems.
Hao: Does this group need to describe relationships between
services?
Jonathan: No. Glen/Tom have requested a straw poll.
Dave: Phrase this as: Should this group accept the proposal and
continue work on it?
Sanjiva: Suggest the question should be: Should be accept Attributes as
a WSDL Requirement?
Roberto: Should Attributes be part of the Component Model?
Jonathan: The straw poll is: How many want to continue work on this? 11
against and 7 for.
-----------------------------------------------------
10:50 Break
11:15 Attributes (cont)
-----------------------------------------------------
SteveG: Suggest pursuing Sanjiva's recommendation.
Sanjiva: Explains recommendation in more detail at the whiteboard...
Roberto: Proposes modification on whiteboard. Discussion continues.
Amy: Sanjiva's proposal focuses on SOAP. Will it work with other
bindings?
SteveG: Discusses Requirements for Attributes (see presentation).
Jonathan: Straw Poll: Should we accept Requirement #3 (Attribute is a
First Class Concept): For 9, Against 7. Still no concensus.
Igor: Abstention, we believe that this matter has to be decided by
web services platform vendors. If it becomes a prevailing
case among web service users then it may be taken into the
WSDL otherwise it could be an extension. The solution could
be expressed elegantly either way i.e. attributes in WSDL or
as an extension to WSDL.
Discussion follows on should we have a formal vote.
Jonathan: We need to resolve the issue for Grid. Suggest further
discussion and tabling this for the Sept. F2F.
Umit: Is there a possibility that those who strongly object will
reconsider?
Glen: I strongly believe this should be an extension. But I could
change my mind.
JeffS: I can't form a position at this time. I need to give my
coworkers time to review this before giving a MSFT position.
David: I am concerned about creeping featurism. This requirement
could be satisfied with mix in interfaces.
Jonathan: Steve, you can report to Grid that we don't have a consensus
and will continue discussion. We also need to shut down new
features in order to complete the spec on schedule.
Phillipe: The charter will probably need to be extended.
David: I don't take that lightly.
---------------------------------------------------------
12:15 Lunch
Scribe: Amy
---------------------------------------------------------
13:15 R085 Describing endpoint references. [14]
- 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 [15], response from Arthur [16].
- Related issue (?) dynamic discovery of a service [17].
[14]
http://lists.w3.org/Archives/Public/www-ws-desc/2003Apr/att-0088/R085-20
03-04-22.html
[15]
http://lists.w3.org/Archives/Public/www-ws-desc/2003Jun/att-0024/umit_pr
oposal.html__charset_ISO-8859-1
[16] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jun/0142.html
[17] http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0004.html
Umit presenting.
http://lists.w3.org/Archives/Public/www-ws-desc/2003Aug/0007.html
R085 cited: "The description language SHOULD allow
describing messages that include references (URIs) to strongly typed
referents, both values and services." Argues that incorrectly worded.
The problem: how describe web service reference, in a manner that can
be transmitted. Must choose XML Schema type, which may need to
represent
a part of a WSDL (an interface/service).
Two languages available for describing the type of an endpoint
reference: WSDL (interface/binding/service), Schema types. Need to use
XSD Schema types. Choice of types is: URI representing endpoint or
possibly representing a "service".
Is a URI all that you need? Possibly an "address" element may contain
additional information. Arthur explains that his proposal includes
possibly other representations of addresses than just URIs.
Primary objection to R085 language is "URI", but uniform references
needed.
Another possible means of passing endpoint information is to supply the
URI pointing into a WSDL document. In all cases, client needs something
in addition to the URI in order to identify an endpoint reference.
Binding information may not be desirable as a part of the additional
information supplied with an endpoint reference; interface information
is always desirable. Arthur's proposal generally includes this binding
information.
Proposal is that there is a canonical type for endpoint references, such
that when it is received it is unambiguous that it is an endpoint
reference. The strong typing of an endpoint reference does not resolve
the issue of identifying the interface, which therefore must be supplied
in addition. This may appear as a type inside messages at design time
(as well as appearing at run time).
There are several ways of associating the interface with the endpoint
references:
1) schema annotation
2) schema extension
3) declaration
Annotation requires knowledge of the WSDL when creating the schema
(potentially circular).
Schema extension adds an attribute in the WSDL namespace to the
element declaration.
[discussion of a third, declarative method, without a great deal of
explanation; scribe unable to follow well enough to describe]
Proposal suggests that placing the reference in the service element
preferred.
Contents of ws-reference type. Contains service (by QName), optional
endpoint (by ncname), optional WSDL location (by URL). Must download
WSDL to get endpoint URL.
Questions about content of proposed type. Question about whether
this requires an additional roundtrip. Case of dynamically generated
service counterpoised. Question of whether the type should contain
sufficient information to make contact (URL of endpoints) or if
stuffing all this information in is superfluous.
OGSI has serviceReference, similar. Simply returns content of service
element (possibly filtered).
Also possible to use the definitions element, with only the relevant
service element; if need interface, then use an import. Questions
about the weight of transmitting a WSDL. Argument over whether a
WSDL instance is identical conceptually to a reference. Discussion
of what information needs to be sent. Should it be possible to send
a whole WSDL? Should it be possible to supply less information?
Several arguments that there are smaller definitions.
Advantages of a new type: always possible to identify a reference;
this is not true of URI (which may not be a reference, and which
does not contain enough information to use it as a reference). Use
of the three mentioned forms restricts the type to use with a
particular interface.
Arthur: review of presentation. Inheritance versus aggregation:
shows use case for why one might wish to use references. Two ways
of identifying when a thing (URL in the example) is a reference.
One form uses an XPath in an endpoint element inside the
input/output/fault element. This means that WSDL decorates the
type inside the WSDL. Second way of doing it is to create a type
in the schema for each interface, and use the endpoint element to
identify the types declaratively.
Endpoint element has a required name attribute, required interface
attribute (a QName), and either an xpath attribute or a type
attribute (as discussed above). This could point at a URI or at
some other address element. Endpoint element also must appear in
the binding. Discussion of whether the binding/endpoint element
is really necessary.
Why not annotate schema? Messages less reusable; couples interface
and binding; couples XSD and WSDL; inconsistent with layering.
Falls into discussion of details.
Why use XPath instead of Schema Component Designators? XPath allows
use of runtime data (major power user bonus say some; others call
it hack). XPath more mature.
Summary: proposal satisfies R085 with relatively little intrusion.
David Booth: workaround is to do it at application level. Suggests
that lack of this facility in WSDL core is not a big problem.
Proposes that R085 be rejected.
Straw Poll: Will a solution for R085 be provided in this version
of the spec? Six in favor, three against, one abstention. Tom
Jordahl suggests that consensus is not achievable; Jeffrey
Schlimmer likewise suggests problems.
Close of meeting.
Received on Wednesday, 6 August 2003 13:16:53 UTC