- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Tue, 24 Aug 2004 12:17:59 -0700
- To: <www-ws-desc@w3.org>
Minutes, 4 August 2004 FTF, London
Web Services Description Working Group
Present:
David Booth W3C
Allen Brookes Rogue Wave Software
Helen Chen Agfa-Gevaert N. V.
Roberto Chinnici Sun Microsystems
Glen Daniels Sonic Software
Paul Downey British Telecommunications
Youenn Fablet Canon
Hugo Haas W3C
Jacek Kopecky DERI
Jonathan Marsh Chair (Microsoft)
Jeff Mischkinsky Oracle
David Orchard BEA Systems
Bijan Parsia University of Maryland MIND Lab
Arthur Ryman IBM
Igor Sedukhin Computer Associates
Asir Vedamuthu webMethods
Observers:
Anish Karmarkar Oracle
Regrets:
Ugo Corda SeeBeyond
Martin Gudgin Microsoft
Peter Madziak Agfa-Gevaert N. V.
Jean-Jacques Moreau Canon
Jeffrey Schlimmer Microsoft
Prasad Yendluri webMethods, Inc.
Scribe: Asir
-------------------------------------------------------
Wednesday 4 August
-------------------------------------------------------
Marsh: outlines changes to the agenda
09:00 Primer
- Overview from DBooth, next steps
Primer is available at http://www.w3.org/2002/ws/desc/wsdl20-primer
DavidB: describes the structure of the primer doc. There is a pile
of miscellaneous topics, section 5. Status, we have rough
material for all the sections. Will rely on experts for
independent topics, primer editors will be contacting them
Marsh: How synchronized is the primer with the LC drafts?
DavidB: Should be mostly. Any comments?
Glen: Looks good
WG: Do you have enough resources working on it?
DavidB: At the moment yes, except for the pile of misc topics
Arthur: Re-iterates his request for validated examples
DavidB: Primer will cover only the core, not all the features; primer
will provide enough basis to use the spec as a reference.
Publish a WD by end of Aug or early Sep. It is little odd
that the primer is a REC
Pauld: Request text on "is WSDL 2.0 suitable for REST interactions,
and if so how do you do them?" and "what is the RDF mapping
for?"
Marsh: It is easy to add items to the pile of misc topics, we have
to make sure that these topics are useful
[Discussion of constraints around contributions from experts on advanced
topics.]
DavidB: Changes between WSDL 1.1 and 2.0 are described in Part 1
Pauld: Expect a note on how to map from WSDL 1.1 to 2.0
DavidB: Nope, primer will not cover it
GlenD: Schema primer is useful, elementFormDefault q vs. uq, would
expect a similar approach in WSDL primer
Marsh: Section 5 may contain best practices that some members may
dis-agree
[may be a strawpoll to gate what is in section 5]
WG: Thanks David and Kevin for the good work
DavidB: Examples may not be correct, WG can help us
10:00 Glen: Property "required"
Glen: Composition model
Marsh: Is this a last call comment?
Glen: Yes
[Last Call Documents are on TR page!}
[dbooth: Last call document listed: http://www.w3.org/TR/]
Glen: The required attribute on Property element is ridiculous
Roberto: Agrees
Glen: Describes using an example, security feature
Allen: Are you saying that the requiredness will come from a
feature/module spec?
Glen: Yes
DavidB: You would always use properties in conjunction with a feature,
so you don't have to declare that they are required
DOrchard: mustUnderstand is extrinsic to feature/module and draws a
parallel to property/@required. Wouldn't the required
properties be listed in a feature/module spec?
Glen: Yes
[dorchard: mustUnderstand is external to a particular spec, isn't this
like property:required.]
Anish: Properties are independent of the features, are env variables,
req or optional is irrelevant, is that your argument?
[dorchard: to which Glenn sez "a feature is required and can be speced
in wsdl. But a property is req/optional by a feature. The
prop might be set by run time"]
[I hear lots of yes from Glen]
[properties are used in conjuction with explicit or implicit features]
dbooth: It is not clear on how the properties are used when explicit
features are not declared in WSDL
[pauld: properties are uniquely identified by a URI, so don't need
a feature for scope, no?]
jeff: There may be implicit features and may consume one of these
properties in WSDL
dbooth: what about interop?
jeff: agrees that this will lead to interop problems
Marsh: lets look into what Umit is loosing if we adopt this
[really, MAY lead to interop issues -- but this really has little to do
with requiredness of properties, but comes from the fact that the WSDL
doesn't contain the entire description of "the contract". You have to go
read the feature spec, which is not machine processable, to find out how
the feature works]
[pauld: introduced endpoint as an example of an implicitly 'required'
property]
Glen: re-iterates that the req/opt, must, default/fixed values, etc.
will come from a feature/module spec. Depending on the presence
or absence of a value, feature/module runtime will react, say
use
default value or fail.
Jeff: Property model is broken, they are just global variables
dbooth: Why is it broken?
Glen: It is about having floating properties shared by multiple
features/modules
[observe little confusion on what is the issue]
Marsh: lets go back to Umit's response
Roberto: why should WSDL declare them
Jeff: outlines Umits pushback
Pauld: it is non-sensical to have a required flag on property
Igor: feature may say that a property is optional but an endpoint may
say that it is requried. How do I declare that property
requiredness in WSDL?
Glen: That is a weird case, feature designer should provide an
additional knob to control it
[I heard tri-state]
Pauld: Would it be useful to have a feature description language
Glen: We have talked about it
dbooth: You are welcome to the constraints and capabilities workshop
[pauld: looks forward to seeing the WS-Addressing F&P spec]
Allen: Igor likes to refine an existing feature by tweaking the
properties, say optional to required
DaveO: How far do we want to go? This is similar to schema
restriction mechanism
[btw, schema keyword is SUBSUMPTION]
Glen: Acknowledges the 2 cases described by Igor, are they important?
Igor: I can use a policy mechanism to declare them
Marsh: Do we have to explain these scenarios if we remove this
required flag?
Glen: No, not in our spec
Straw Poll: how many are in favor of removing the required attribute in
the property element?
favor = 10,
oppose = 1,
abstain = 2
[GlenD: Explaining these (and other) scenarios is certainly going to be
important, it's just that we don't need to do it normatively, IMHO.]
RESOLUTION: to remove the required flag on property element and make
appropriate changes to the component model
10:50 Schema Versioning Task Force - where do we go from here?
- DaveO: versioning
Marsh: Introduces the topic, describes how fuzzy it is, may be
will generate a few last call issues
[turning over to DavidO]
Marsh: Looking for concrete things for WSDL
[tech difficulties]
dorchard: "WSDL: Versioning" Introduces a new topic, INTERFACE
Versioning
[dorchard will post his slides later, please insert link here]
dorchard: Proposal to
(a) add primer material to say that optional messages should
have defined behavior
(b) add a "compatibleWith" boolean to interface
Marsh: Didn't we consider this solution before
dorchard: This works only in conjunction with extends attribute
Allen: Request dorchard to relate his proposal to the problem space
in the previous slide
[pauld: supportive of the compatibleWith attribute combined with
extends since there is a relationship with the explicit
relationship with the original version. It solves my
issue of the version attribute implying transitive
compatibility]
dbooth: Is your definition of compatible transitive?
dorchard: Yes
dbooth: If it is incompatible, why wouldn't you justify that as a new
service?
dorchard: Sure, you can
dbooth: Then, why do you need this?
dorchard: But, in practice, they want to use the same endpoints
[we are running out of URIs]
[pauld: Also wanted to express how important mustIgnore is to BT.
We're
at a point of publicly discrediting toolkits which don't
employ
the mustIgnore rule.]
Roberto: I don't get when you claim that this isn't choreography?
dorchard: Would you accept that it doesn't get very far
Roberto: Agree, then it doesn't belong in the description
Bijan: Where does it belong? should we coordinate with Choreography?
Roberto: Definition of message optionality is vague, this is a fairly
rough weapon that you are attempting to deploy. Good solution
should be specific. But, that gets into the choreography
space.
We need a new relationship between interfaces, interface A
extends B (compatible), interface A includes B means lexical
include, may be that is the right thing to do. Semantic
extends vs. syntactic include
[Roberto: It wouldn't quite be a lexical include; essentially, if
interface A includes B, A would contain carbon-copies of
the sub-components of B, adjusted to be correct in the
context of A per the component model rules. The "extends"
relationship would be reserved for compatible/semantic
extensions, which are natural to developers from their
experience with programming languages]
[pauld: +1 to roberto's new relationship verb]
jeffm: Agrees with Roberto's to establish a new relationship, 'cos
in normal practice people used substitution and inheritance
as substitutes for versioning
igors: Talks about versioning discussion in the ws-management tc
(OASIS), there are limited cases that can be done using WSDL,
say for example, changes to binding, endpoints, types. You
need some extrinsic information about what has changed, say
interface changed, binding changed, etc. There are very
limited
cases that we can do it within WSDL. Such a situation calls
for an external solution.
[igors: e.g. a formalization of one's CVS log with regards to the WS
endpoint being deployed. WSDM TC has a requirement to address
versioning too. That is WS versioning management...]
[glad you mentioned that]
[pauld: But CVS describes the chain of change, but communicating a
break in compatibility is left to informal comments]
Marsh: Summarizes, some solutions to explore, lets come back to this
dbooth: Concerned that we may end up endorsing a solution that re-uses
the same uri
[pauld quotes a BT example]
[igors: Paul, I meant in a "spirit" of a CVS log. In reality one needs
a markup of a "revision" which indicates a NUMBER of "changes"
which are attributed with "compatibility" and refer to "what"
(e.g. XPath)]
[i hear music]
[pauld: A company could have a single endpoint for the whole company,
e.g MQ://www.bt.com which authenticates and then routes
messages to appropriate service.]
12:00 Lunch ----------------------------------------
Scribe: Jacek
Jonathan talks about the rest of the agenda
13:00 DaveO: Multiple namespaces and schemas
Daveo: Now that our bindings are layered (SOAP on top of HTTP),
the rationale for multiple namespaces is significantly
reduced.
We don't have a schema for our bindings because of
extensibility vs. wildcards
Glend: Why?
Daveo: We can't have a schema because an optional element from a
different namespace cannot be followed by a wildcard
[pauld: Wonders how this relates to his 'collapse binding namespace'
proposal:
http://lists.w3.org/Archives/Public/www-ws-desc/2004May/0063.html]
Glend: We have schemas for the extension elements, separately
Daveo: We cannot restrict the occurrence of the extensions in WSDL.
The other solution is just to make all in one namespace, then
you can write a schema controlling where it all goes
Glend: Only solves the problem for our elements, doesn't help other
Extensions.
Daveo: Yes
Glend: It doesn't gain us a whole lot *and* the current approach
demonstrates our idea of extensions in different namespaces
Daveo: There are few or no extensions out there apart from ours
JacekK: Systinet puts extensions in its WSDLs
Glend: How about giving them a WSDL validator, they won't need so
much a schema validator doing as much as possible
Daveo: One bar for partial validity is schema-validity
Bijan: Is there a reason for "demonstrating the extensibility
architecture?"
JacekK: Signaling that the extensions are in fact extensions
[Roberto: +1 to Jacek's comment]
JacekK: Also, reuse of the current extensions (would-be options) would
be limited
Jonathan: Our attributes are limited to our elements
Daveo: Am I the only one who finds the status quo of mixing various
namespaces weird?
Glend: No, we had a similar proposal before
Asir: Daveo, you mentioned about the issues that I pointed out in
your sample WSDLs, most of those are described in Part 1 WSDL
core schema and the rest are semantic issues, that cannot be
described using XML Schema. Using one namespace will not help
you in these specific cases
Glend: (possibly pauld's point) maybe we should just drop
wsdl:binding
and replace it with soap:binding. This proposal was shot
down.
Pauld: The proposal was in two parts, both "too far"
Glend: Realistically, the optionality would not be so clear if we had
only one namespace
Jonathan: With only the WSDL namespace schema, I get incompletely
validated instance, but all WSDL stuff is validated
JacekK: Schema not being fixed yet is too little of a rationale for
changing the status quo that is intuitively designed
Jonathan: All validation tools have a point where they will just leave
off
Daveo: I agree there is a bar and I'd like our things to be inside
the bar. While we cannot do anything about the greater schema
extensibility problem, we can do something about our
extensions
Pauld: In a few years, for example our bindings could become replaced
by a new cool binding everybody agrees on, so then the value
we'd get from putting our stuff in one namespace would be
greatly diminished.
Daveo: Schema has the same namespace in two documents
Jonathan: Our case is breaking the spec (and namespace) so that people
can reuse parts of it
Asir: We should have split the namespaces as well in schema, into
three: structures, extensions, simple types
Strawpoll: how many folks like folding our namespaces into one?
1 strawvote for, 9 strawvotes against
RESOLUTION: dropping the idea of folding namespaces into one.
13:45 Test suite and QA
- Survey expected implementation schedules
- Arthur: review formalizations in the spec. e.g. remove the
ambiguities
Arthur: Presents his slides
Roberto: Additional aspect: does a processor construct the correct
component model?
Arthur: Schema validation, for example, doesn't touch components
Roberto: The constraints are mostly phrased in terms of component model
Arthur: You're getting into how validation works, but what we're
validating is documents
Roberto: I think we should still test the interpretation of the WSDL
doc into component model
Arthur: We have WSDL spec, particular documents, and those are valid
or not
JacekK: Testing the interpretation of a WSDL document into a component
model is not doable
Arthur: We don't define language bindings and the component models
in implementations are in programming languages, not testable
Roberto: We could define a simpler serialization
Arthur: That's something extra. When talking about processors I
meant passages like "processor ignores, fails etc."
[presentation continues]
Jonathan: Don't see a need for a new ML only for testcases. We could
have
a Mailing List for testing purposes
Hugo: Schema had a list that specified that submissions there were
licensed by the author the right way
ACTION: Jonathan to check the policy with AB and team and perhaps set
up a ML for testing.
Pauld: I'm creating tests, each is uniquely and stably identified.
Wondering about the life cycle of a test.
Jonathan: So we have two things: test submissions and building the
actual test suite
[hugo: XMLP test suite contribution:
http://www.w3.org/2000/xp/Group/1/10/ts-contribution]
Jacek: XML Schema WG has done substantial work on how to collect
test cases, process, patents, etc. I bet that we can learn
from them. I request the WG to look at schema wg test page,
http://xw2k.sdct.itl.nist.gov/tonyc/xmlschema2004-01-14/
Anish: XMLP created a list of features from the list of MUSTs and
SHOULDs (and MAYs), then cross-referenced that list to
actual tests. Then it's possible to see which of the
features are or are not covered
Jonathan: We decided to have a bit of markup around the assertions
(MUSTs etc.)
Arthur: That's not sufficient. We can already assume well-formedness
and validity against schema. We should have docs tho that
validate against schema but violate other syntactic
constraints from the spec
[presentation continues]
[pauld: The test coverage tool may also be used to categorise our
pool of tests]
Roberto: Does Z notation use a lot of special symbols?
Arthur: Not too much
Jonathan: We could embed XML markup representing Z in our spec, right?
Arthur: Yes, we could replace the pseudoformal text by the Z notation
Jonathan: To do WSDL in infoset, we can use only a small, simple subset
of Z
Arthur: There are three types of information in part 1, I've only done
the component model. The others include the mapping of that
to XML and interpretation
Roberto: The text is clearer than what we have in the spec, right?
Arthur: Yes, because the exercise of formalization has preceded it
Pauld: And in this version the sections are consistent in structure
Arthur: This approach also forces you to catch all the hidden rules.
My exercise actually resulted in comments simplifying the
Spec. Z also allows reuse, all qnamed components can be
modeled as such.
[arthur goes through his comments created during the formalization]
Arthur: So I suggest that as soon as we get the HTML rendering OK we
try a version of the spec written in Z
Jonathan: Let's first do a side-by-side comparison of the two versions
Hugo: How much work is it to produce the XML vocabulary for Z?
Arthur: Not much. I think we could do a decent job...
Jonathan: Seems like formalization is great for uncovering stuff, but
it cannot cover advice or intention
Arthur: Z notation is not the only normative part. There are still
unclear parts of the spec, specially in the area of
processors. Right, Z cannot give you a 100% coverage, but
the more the better
Roberto: As a schema implementor and user I'd like to have the same
thing done for Schema
Pauld: Henry Thompson invented his own formal notation, own logic
Roberto: How does this relate to testing effort?
Arthur: The component model is now represented as a set of formal,
testable assertions
[pauld: A Logical Foundation for XML Schema:
http://www.idealliance.org/papers/dx_xmle04/html/abstract/02-06-02.html]
Arthur: I was trying to express these assertions so that they easily
map to a programming language. Further, the assertion has a
clear name. The three parts of the spec are: abstract
component model (done in Z), constraints on the infoset
(translatable to XML Schema), the mapping between. To do
the mapping we'd need to formalize the infoset constraints
as well.
Asir: Thus far XML Schema has gone through 4 forms of formalization
That taught us about a lot of issues. Schema is much more
complicated than WSDL, has 5 parts.
Pauld: One of the benefits is that it's more readable by removing
semi-formal English; this hasn't really succeeded in XML
Schema, right? I feel very positive about this direction,
I think we should endorse it
Jonathan: We should not push it too far though
Arthur: Z was invented for unclear programming languages. Z is a
formal spec language, we are writing a spec. 8-)
Asir: For a subset we can be successful
Arthur: The biggest bang for the buck is formalizing the component
model
Roberto: The hardest part to write is the infoset constraints, I'd like
to be able to generate that
Arthur: I started from the infoset, then did the component model and
could finish with the mapping
Jonathan: Let's wrap up. Thanks to Arthur for all the work on this,
and to Paul for joining in as well. We'll be working on the
XML notation of Z and the stylesheet. Then we can compare
with the status quo, judge utility, see how much of spec is
removable as effect. Still worried about the
understandability of Z for our audience
Arthur: We could have a simpler version with that removed
[pauld: an appendix which explains the vocabulary of Z we're using ..]
Arthur: Would like to work with the editors
[nobody disagrees with pursuing this path, deciding later]
Roberto: But would we need a normative infoset formalization?
Arthur: That's pretty simple
Jonathan: XML Core could be interested in this.
Jonathan: Schedule? getting a side-by-side version by the next f2f?
ACTION: Arthur and Jonathan to produce a mockup of Z in the spec for
next FTF.
15:00 Break ----------------------------------------
15:20 Review master schedule for next 12 months, expected
deliverables, expected workload.
Jonathan: Our schedule calls for CR in October, depends on the scale
and number of LC comments, we might be able to meet it.
Still have to publish a WD of the primer, perhaps LC of
the media type spec. RDF mapping, primarily Bijan's work,
we'll see at next f2f. Basically we don't have massive
problems with scheduling. The CR phase could take a bit,
expect Rec next summer-ish.
PaulD: To help testing, test cases can be used as canned services.
Jonathan: And we don't mind sticking in CR if that actually improves
our spec
Jonathan: c'ya in September, thanks to Paul for hosting and the
executive treatment we've received
ACTION: Hugo to set up Sep f2f registration page
we call it a week
16:00 Adjourn
Received on Tuesday, 24 August 2004 19:18:36 UTC