- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Mon, 29 Sep 2003 17:09:38 -0700
- To: <www-ws-desc@w3.org>
Web Service Description Group
Minutes, FTF meeting 22-24 Sept 2003
Palo Alto, hosted by SAP.
-------------------------------------------------------
Wednesday 23 September
-------------------------------------------------------
Present:
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
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
Steve Tuecke Global Grid Forum
Phone:
Amelia Lewis TIBCO
Jean-Jacques Moreau Canon
Prasad Yendluri webMethods, Inc.
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: Umit
09:00 [Attributes | Endpoint References as needed, otherwise:]
Issue 2: SOAPAction has been deprecated, as of SOAP 1.2 [40].
- Arthur's proposal to unify property URIs and QName URIs. [41]
Alternatives include using property markup, or a QNamed
attribute.
- Proposal for advertising QoS features of a Web service in WSDL
[42].
[40] http://tinyurl.com/mwuy#x2
[41] http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0047.html
[42] http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0020.html
Arthur's proposal to unify property URIs and QName URIS.
What should be property or extension?
Glen: Things affecting tools should be extensions, semantics
affecting interactions should be properties/features.
Sgg: Is it ws-policy?
Glen: This question should be resolved. This would be in the
primer.
ACTION: Glen to clarify when to use the open content model and when to
use the properties/features in the primer.
Arthur's proposal [41]
<property uri="http://www.w3.org/.../soap/SoapAction">
<value>http://example.com</value>
</property>
Arthur: This is verbose and generic content model. Schema validator
can not impose the constraints. Propose to translate the form
into namespace + local name as illustrated below.
<soapaction xmlns="http://www.w3.org/...">
http://example.com
</soapaction>
Schema is
<schema ... targetnamespace="http://www.w3.org../">
<element name="soapaction" type="anyURI">
</schema>
This allows schema validation.
?: How do you distinguish between the extension and properties?
Arthur: In the document, there is a decl which indicates the namespace
to be a property namespace.
<wsdl:declaration ..../>
Glen: We should keep the other syntax. For enumerations, it is easier
to express with the property syntax.
Sanjiva: The schema validation holds true for any syntactic sugar. RPC
pattern has the exact property. Therefore, the argument is
not compelling. For example we can use the xsi:type to designate
the values with another attribute.
Arthur: This translation gets the schema validation for free.
Roberto: Extensibility already provides this functionality.
Jeff: I like it because it is familiar. What does it mean to require
a property?
Glen: It does not make sense. When we say required on an extension,
the processor must understand. This does not apply to
properties as properties must be made available by the processor
so setting the value does not make a difference.
?: When do properties come up? In the context of the feature?
Glen: The properties are to be made available to the property "set"
regardless whether a feature is used. The contract is to make
the it available. When you set a propery uri, it is ...
Phillipe: If we don't set the feature, how can I reuse the property?
Glen: The reuse them between the feature is to reuse the value.
<scribe missed the answer>
Roberto: Lets postpone this discussion. The mechanism has to be defined.
What this adds to the existing to the extensions to be marked
specially (which they you don't know what they do as you may
not understand the extension in the first place.
Arthur: If we have this, for example, JSR 110 can extract the properties
and store them. The generic processor does not have to
understand, a different step (processor?) can evaluate the
properties on top of the generic processor.
[jeffs provies the table for comparison.]
[plh-lap: Jeffrey table:
http://www.w3.org/2003/09/0924-ws-desc-properties.html]
Philippe: Why should be restrict it to a simple type?
Glen: We should not. It is not restricted in the soap spec.
Arthur: Properties are defined in the spec. This is an alternate and
simple syntax. Lets decide and move on.
Straw Poll:
In favor : 7, against: 4
Sanjiva: I am not convinced that we need to shorter syntax.
Paul: I am not sure when to use the extensions and properties.
Jonathan: Table this issue and track it before we make a final decision.
[40] is deferred.
[pauld: I'm still unclear when to use a property or when to use an
extension - i'd like some concrete examples
ACTION: Jonathan to look into [42] and evaluate relationship with
properties/features.
-------------------------------------------------------
09:45 Media type handling in WSDL 1.2 (Philippe) [43, 44, 45]
Done Monday:
-------------------------------------------------------
10:00 WSDL Component Designators [46]
Draft TAG finding [47]
[46] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0075.html
[47] http://lists.w3.org/Archives/Public/www-tag/2003Jun/0054.html
[No minutes? Chair recalls that we were unable to quickly choose an ideal
candidate from the TAG draft finding, and thus approved moving the appendix into the RDF mapping document to eliminate a dependency of unknown duration.]
-------------------------------------------------------
10:30 Break
-------------------------------------------------------
Proposal for shortcutting operation syntax
[48] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0178.html
Roberto: The fault rules do not make the in/out fault elements redundant.
Amy: Message ref may be made optional is a good idea. I oppose
making the pattern attribute optional. Requires writing the
tools more complicated and would allow variability in the
implementations. For example, some implementations will never
look for patterns, only implement wsdl1.1 patterns.
Sanjiva: This is not to change to change the component model. The
operation component must have the pattern associated with it.
Paul: Agrees with Amy it will lead to interop problems.
Umit: Observes that this is again a syntactic sugar.
[alewis: I like the consistency provided by required @pattern, too.
Easier to explain. No exceptions.]
[jeffsch: This http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.xml#InterfaceOperation_Mapping
Mapping for {message exchange pattern} would look something like:
The actual value of the pattern attribute information item, if
present; otherwise, if there is only one message reference in
{message references} and that message reference has {direction}
equal to 'in', then 'http://www.w3.org/2003/06/wsdl/in-only';
otherwise if there is only one message reference in
{message references} and that message reference has {direction}
equal to 'out', then 'http://www.w3.org/2003/06/wsdl/out-only';
otherwise if there are two mes...
Umit: Agrees with amy.
[Chair: Defer vote until a telcon rather than perpetrate rash judgement.]
-------------------------------------------------------
Proposal for making messageReference optional.
Roberto: It is already optional in the spec.
Sanjiva indicates that it is not complete, and requires more clarification.
[Roberto: I agree.]
[alewis: +1]
Jonathan: Shall we leave it as optional and add more clarification?
Umit: +1
[alewis: It might be better to phrase it as "the message reference
attribute is required, if the pattern contains more than one
message in a given direction." That is, rather than describing
when it can be optional, describe when it must be used.]
[Roberto: And how do you find out what the correct message reference names
are if you run into a pattern you don't know about?]
[alewis: How do you do anything useful with a pattern you don't know
about?]
[Roberto: You can still build the operation component and all its children.]
[alewis: *shrug* Make a rule in the patterns section that if a pattern
contains only a single message in a particular direction, its
name is "input" or "output" (depending on direction).]
Lily: This proposal is only for human consumers, not really for the
wsdl generators.
Tom: Argues that even if we define a pattern attribute, the processor
will stop when there is an unidentified pattern anyway. The
processing does not change, you need to do the validation anyway.
[alewis: No.]
Sanjiva: Is it worth adding it as it covers 90% of the cases?
Amy: Does not agree that this is 80/20 case.
[jeffm: VOTE, VOTE, VOTE, VOTE, VOTE]
[pauld: I think choice is a bad thing - I want canconical sytax.]
Straw poll:
4 opposed. 8 agreed. 1 abstain.
jj: Compilates the compilation.
We will vote on this next telcon after more review.
Jeffsch: There is an issue with the current with the spec as is which
needs to be resolved.
-------------------------------------------------------
Proposal for making operation/@name optional
http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0172.html
Roberto: If the interface eliminates the name, the binding can not refer
to it and it is restrictive. The operation is the only way
available for reference in the binding.
Umit: Operation name does not appear on the wire, its only purpose
right now is for a reference only.
Tom: The name is significant for Macromedia's tools for helping users.
Straw poll for adopting the proposal: 6 in favor, 5 against.
We will defer this to a future telcon.
12:00 Adjourn [48]
[48] http://www.cdsusa.com/
Received on Monday, 29 September 2003 20:10:04 UTC