- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Thu, 15 May 2003 03:06:20 -0700
- To: <www-ws-desc@w3.org>
--------------------------------------------------------
Wednesday 14 May
--------------------------------------------------------
Present:
Glen Daniels Macromedia
Youenn Fablet Canon
Steve Graham Global Grid Forum
Philippe Le Hegaret W3C
Kevin Canyang Liu SAP
Jonathan Marsh Chair (Microsoft)
Jeff Mischkinsky Oracle
Jean-Jacques Moreau Canon
Arthur Ryman IBM
Jeffrey Schlimmer Microsoft
William Vambenepe Hewlett-Packard
Sanjiva Weerawarana IBM (till 11:30)
Observers:
Bejan Parsia U of Maryland, Semantic Web
Martin Chapman Oracle
Doug Bunting Sun
scribe: Jean-Jacques Moreau
-------------------------------------------------------
09:00 Properties and features TF report
- Usage scenarios: presentation of simple feature use
(S1 simple feature [10]). Glen will provide the example.
- Go over the list of pros and cons: [11]
- Glen will illustrate more on how the ability to have a
generic context by using properties will be useful for
simplifying WSDL processor and their extensions.
- Proposal for advertising QoS features of a Web service
in WSDL [12].
Issue 2: SOAPAction has been deprecated, as of SOAP 1.2 [13].
- Jean-Jacques proposal at [14].
- Jacek's addendum at [15].
- Proposal from Glen at [16], fix from JJM at [17]. Undecided on
whether to allow WSDL 1.1 syntax, PnF syntax, or both.
- Waiting for guidelines from PnF TF.
- Alternate (?) proposal from JJM to allow arbitrary setting of HTTP
header fields [18]
- Is "FnP for HTTP binding and SOAP HTTP binding" [19] a friendly
amendment or an alternative proposal?
[10] http://dev.w3.org/cvsweb/~checkout~//2002/ws/desc/wsdl12/wsdl12-pftf-usage-scenarios.html#S1
[11] http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0016.html
[12] http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0020.html
[13] http://www.w3.org/2002/ws/desc/2/06/issues.html#x2
[14] http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0050.html
[15] http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0056.html
[16] http://lists.w3.org/Archives/Public/www-ws-desc/2003Apr/0010.html
[17] http://lists.w3.org/Archives/Public/www-ws-desc/2003Apr/0022.html
[18] http://lists.w3.org/Archives/Public/www-ws-desc/2003Apr/0028.html
[19] http://lists.w3.org/Archives/Public/www-ws-desc/2003Apr/0025.html
Brief presentation by Glen, SUBTITLE: "Une petite histoire"
Glen: Feature is a piece of semantic. Specs define distributed
state machines. Property is a piece of context used by
the state machines. There is a virtual "execution context"
(i.e. state) which is shared by the entire SOAP processor
(Web Service) (called Message Exchange Context in SOAP
spec) It only makes sense to specify properties whose
values are user controllable (according to their spec).
Properties can contain multiple features. Properties can
be shared by multiple features. Hence they are modelled
as "top level" components.
Marsh: Is this introductory material in the spec?
Glen: No yet
Marsh: Will need to go in spec later
Glen: Properties contrains/values are used to set up an initial
execution context. Context contains the marged values for
properties at all active scopes (operation, binding,
service). Rules for setting up execution context prior to
performing an operation are implicit. At some point, some
API needs to be called:
- specific: thing.setSOAPAction(...)
- generic: thing.setProperty(p, val)
Generic API reduces coupling between WSDL and SOAP software
WSDL just needs to know how to setup the context, not the
lowest level API.
Example: reliability
Remove SOAPAction?
(end of presentation; Glen moves to the whiteboard)
Glen: Difference between:
<prop uri="http..."><value>foo</value></prop>
and:
<action>foo</action>
?
[Turning to Philippe's message on pros and cons, see http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0016.html]
Philippe: CONS
- Features are more verbose
(bug fixed in Philippe's message; no need to declare
SOAPAction feature)
Glen: No need to declare optional features
Doug: How to describe interaction between state machines of
different features?
Glen: Not possible, in general.
JeffM: No different from SOAP header blocks
Glen: Syntax little bit longer. No schema.
Marsh: No way to say where it appears.
Glen: Issue if set same property at different levels; lower
level should win. Issue with validation, although
similar problem if using extensibility element: schema
has to be fetched as well. Departure from WSDL 1.1
syntax.
Philippe: soapAction was an attribute.
Jeffsch: Does SOAP have syntax for features and properties?
Glen: No, this is what modules would do, none available so
far.
JJM: Eventually, the header block is the syntax for the
feature and its property.
Philippe: PROS
- Reusability of properties
Jeffsch: We either have a QName or URI
Philippe: - Louse coupling
- Constraint syntax allows reducing the value set
(instead of simply setting the value)
(otherwise would need specific syntax for each property)
Other advantage is finding all properties for a given
operation (using XPath and/or XSLT)
Glen: Both modes have good use cases. Similar to authoring
style for XML Schema (attribute vs. elements)
Jeffsch: What's the underlying issue?
Glen: Whether people are going to be confused with alternative
syntax.
Jeffsch: Users already know extensibility via elements; they will
only need to grasp the new feature/property syntax.
Marsh: Issue mostly for spec authors.
Jeffsch: We are spec authors (HTTP, SOAP bindings, possibly header
blocks).
Marsh: Which parts should use features, which part should use
elements? Likely confusing.
JeffM: Abstraction opens door for potential new problems?
Glen: No different from anything else.
Marsh: No guarantees that because abstract everyone will do it
in consistent manner.
JeffM: ok
Martin: Relationship to ws-policy, etc?
Glen: Similar to WS-Policy, which has IP issues?
Jeffsch: Workshop being organised, interop tests, then move to
standard organisation. Few people at first, make it
work, then standardize.
Martin: Pity to have separate discussion if significant overlap.
Marsh: Very differrent approaches, here add something which
might not be needed.
Glen: Would say yes if was only WSDL; but in SOAP.
Marsh: And exactly how W3C proceeds anyway everyday.
Glen: Technically, a lot of overlap.
Marsh: Subset or superset?
Glen: Policy 1) wraps semantic behind identifier; 2) does not
provide way to choose between 2 options
Jeffsch: Pick one; pick one or more; choose preference. However,
features revert to english at end of day.
Glen: Maybe the difference is ...
Jeffsch: Decision tree.
Glen: Domain assertion specific.
Jeffsch: Wouldn't be able to use XPath expression.
Sanjiva: WS-ReliableMessaging uses properties, although domain
specific.
Martin: Dilemma: interested in policy, but not involved, which
one to choose?
JeffM: Is politics, products involved, resources, customer
education, etc.
Jeffsch: Group decided for features and properties, although
MSFT voted against and may file minority, but currently
watching how things progress.
Glen: Will test for WSDL 1.2 trigger SOAP layer?
Marsh: Yes, eg. soapAction
Glen: Could do same for features, for example value of
soapAction.
Marsh: Yes for the ones we built into the spec.
Glen: ... could be as well features implemented as SOAP
header block
Marsh: Skeptical that could get rid of features as late as
CR phase
Glen: More Last Call thing.
?: Depends if our own work uses features and properties.
Marsh: 1) decide about soapAction (and webMethod) or 2)
revisit our decision?
Jeffsch: Claim usability is the same (QNames or URIs)
JeffM: If keep properties and features syntax, have to use if
for soapAction and webMethod
Marsh: Poll: 1) QNames or 2) URIs ?
Glen: Only value of properties if tool can do some useful
thing with them without understanding them.
Arthur: How?
Glen: If deal with multiple binding without getting into the
details, can set a bunch of random properties
Arthur: How if random?
Glen: Are understood by back end.
JeffM: How do you communicate them to your SOAP processor.
Glen: Per value, or bag of properties.
Arthur: Meaningful?
JeffM: Generic interface?
Arthur: Could use DOM tree.
JeffM: Could do a lot of things if some things were also
standardized; at end of day, specific to implementation
Glen: And don't want to set APIs, but not huge issue.
Arthur: Similar to WebDAV
[Youenn: Glen: with the qname syntax, you need to know the qname before to know that it is a feature. With the container syntax, no pb.]
[Youenn: Arthur: define somewhere that a ns is defined for properties and points to a schema.]
Marsh: So drop specific features syntax and have annotation
instead?
Glen: Not annotation, but as following example:
<soap:operation x:soapAction="URI2"/>
<extension-ns-is-a-property ns="URI1" xmlns:x="URI1"/>
Marsh: Worth exploring. So straw poll 1) new syntax above or
2) QNames as earlier.
Sanjiva: Still avoiding real question: link to policy and context.
We're trying to deal with this over the phone, PFTF.
Glen: Would like to see specs use SOAP 1.2 style, i.e. features
and properties.
Jeffsch: Not all specs would use that style, but homework worth doing.
Sanjiva: Jeffsch suggesting more concrete syntax; but real question
above still valid.
Marsh: Too premature to decide now on bigger issue?
[Poll:
option 1: features and property elements
option 2: QName (element or attribute)
results:
option 1: 7
option 2: 2]
Marsh: So still interest in feature and properties. Arthur to write
up proposal �a WebDAV?
Arthur: If WG interested.
Glen: How define where would go?
Arthur: Maybe using substitution group, as Gudge does.
Glen: Little tricky.
ACTION: Arthur to write up the alternative/WebDAV syntax for features.
--------------------------------------------------------
11:10 Break
11:20 BindingType proposal from Kevin [30]. Updated proposal at [31].
Sanjiva's alternative at [32].
Awaiting updated proposal from Sanjiva.
[30] http://lists.w3.org/Archives/Public/www-ws-desc/2002Aug/0009.html
[31] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0068.html
[32] http://lists.w3.org/Archives/Public/www-ws-desc/2002Jul/att-0117/01-bindings-2002-07-24.html
Binding simplification proposal presented by Sanjiva. See http://lists.w3.org/Archives/Public/www-ws-desc/2003May/att-0046/Simplifying_Bindings.ppt.
Sanjiva: 1) Drop interface from binding, since now in service.
2) Allow inlining interface-wide binding within a port and
make binding optional.
Jeffsch: Alternative: anonymous binding.
Sanjiva: 3) Define default binding. Most likely the moral equivalent
of SOAP doc/lit.
4) Dealing with operation specific SOAPActions.
i.e. default for computing SOAPAction
Summary
* simple case really simple
* (others)
(sanjiva needs to leave)
ACTION: Sanjiva: send presentation by email to start discussion
Revisited BindingType proposal (now BindingDetails) from Kevin.
Kevin: Reusability issue still not addressed by Sanjiva's proposal.
- Factor out binding details in separate, new construct
- Current binding structure remains the same
<bindingDetail name="..."
target="binding/operation/message" ...>
<!-- binding details -->
</bindingDetail>
Marsh: Changes the component model?
Jeffsch: No, not necessarily.
JJM: Yes, need <bindingDetail> component.
JJM: Or maybe not, may only be serialization issue.
Marsh: Gives more flexibility, but adds complexity. Especially
in context of Sanjiva's proposal.
Glen: Makes it hard to look at a document and see what is
going on.
Marsh: Can we relate Kevin's proposal to Sanjiva's proposal?
Kevin: Same goal.
Glen: Ok to merge?
Kevin: Yes, as long as keep same functionality. Small task
force to modify Sanjiva's proposal.
Glen: Only need email on main mailing list. Introduce
referential integrity feature with following properties.
Should be able to put a name att on binding component
which you wish to reuse. That name att (loca name?)
would be qualifiable in references. Sorry, a binding
extension component, eg soap component, would have a
qname. Would enable other extension binding component
to point.
Jeffsch: Interesting scenario: Want to reuse fact that all
output messages will be rpc stuff. Have wsdl:binding,
inside soap:binding, would have to construct dummy
binding to reference. Dummy binding not pointing at
any interface. Just reusing things inside.
Jeff?: Kevin should provide example, to make sure idea of
dummy binding stands.
Glen: Don't know if syntax is different.
Jeffsch: Dummy binding, some operation, not saying what it is...
Kevin: Would be adding new substition group, which adds
complexity.
Marsh: Will try to merge this with Sanjiva.
[Jeffsch: Example like?
<binding>
<soap:binding useDefault="rpc" name="rpcUse"/>
</binding>
And then used like?
<binding name="myBinding">
<soap:binding ref="x:rpcUse" />
</binding>
ACTION: Kevin to contact sanjiva and try to merge proposals
--------------------------------------------------------------------
12:30 Issues 53-55 [20]
- Philippe's proposal for HTTP binding [21].
Generally accepted. Philippe will continue to polish the
Proposal for discussion at the FTF, after which we expect to
roll it into the spec. Examples at [22]
[20] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/issues/wsd-issues.html#x53
[21] http://lists.w3.org/Archives/Public/www-ws-desc/2003Mar/0068.html
[22] http://lists.w3.org/Archives/Public/www-ws-desc/2003Apr/0024.html
Philippe presented the proposal, and syntax examples, to the WG.
Three issues were raised:
1) Reusing {} from XSLT (and the escaping mechanism thereof) instead
of () (and inventing an escaping mechanism).
2) P&F representation of the webMethod (verb). This may need to be
changed depending the outcome of the P&F issues.
3) Whether to allow parts to be encoded as URI parameters when POSTing.
RESOLUTION: Adopt the proposal into the spec. Some parts might need
adjusting later as the rest of the spec changes.
--------------------------------------------------------------------
13:00 Lunch
14:30 Begin Joint Session with WS Architecture
Future meetings
IBM/Toronto Arch: July 28-30, Desc: July 30-1 August
? SAP/Palo Alto Desc: Sept 22-24, Arch: Sept 24-26
? Fujitsu/San Francisco Desc: Nov 3-5, Arch: Nov 5-7
No participants objected to this plan.
--------------------------------------------------------------------
14:45 (WSDesc) Single interface per service implications on
(WSArch) "What is a web service?"
Presented the WSDL definition of Service (<service>) adopted on
Monday. Fielded many questions from Arch, generally about the
term "Resource", and whether each enpoint itself was a resource,
and what the URI of the entire "Web Service" was.
--------------------------------------------------------------------
15:30 Break
15:45 OWL Presentation and Demo on OWL, its value in the Web Service
space, its relation to RDF and the RDF mapping WS Desc is
chartered to produce, and its relation to properties and
features. [Bijan Parsia] [1]
[1] http://www.mindswap.org/~bparsia/talks/may2003-wsd-wg/Overview-3.html
Bijan presented an overview of the technologies, methodologies, and
applications of Semantic Web Services. Key takeaways by the WSDL
chair are:
1) Domain of Semantic Web expertise much larger than previously
imagined, impossible to cultivate the requisite level of
expertise within the WSDL WG.
2) WSDL -> RDF/RDFS/OWL/DAML-S mapping could be owned by either
WSDL WG or by SW. SW gets some advantage from the WS
"brand".
3) WSDL WG needs a member from the SW community to absorb WSDL-
specific expertise - the inverse is not practical.
4) WSDL WG needs editorial resource with expertise from the SW
community. Developing this editorial resource in-house is
impractical.
5) WSDL WG would be happy to devote time to clarifying questions
and proposals from the SW expert. This is more likely to
result in a quality deliverable than simple review by WG
members.
Bijan will take this info back to the SW community as well.
--------------------------------------------------------------------
17:30 End Joint Session
17:30 Adjourn
-------------------------------------------------------
Partial IRC log: http://www.w3.org/2003/05/14-ws-desc-irc
Received on Thursday, 15 May 2003 06:06:28 UTC