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

Minutes, 1 August 2003 FTF Raleigh

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Wed, 6 Aug 2003 10:15:55 -0700
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA2AAAD25@RED-MSG-30.redmond.corp.microsoft.com>
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 GMT

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