- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Tue, 24 Aug 2004 12:16:03 -0700
- To: <www-ws-desc@w3.org>
Minutes, 3 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
Terry Wyatt British Telecom
Simon Thompson British Telecom
Regrets:
Ugo Corda SeeBeyond
Martin Gudgin Microsoft
Peter Madziak Agfa-Gevaert N. V.
Jean-Jacques Moreau Canon
Jeffrey Schlimmer Microsoft
Prasad Yendluri webMethods, Inc.
Phone:
Sanjiva Weerawarana IBM
Umit Yalcinalp Oracle
Tom Jordahl Macromedia
Scribe: JeffM
-------------------------------------------------------
Tuesday 3 August
-------------------------------------------------------
09:00 SOAP 1.1 Binding
- Overview from Asir (Proposal A [20], Proposal B [21]),
discussion about the direction and implications on our
SOAP 1.2 binding.
[20] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0250.html
[21] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0305.html
Soap 1.1 Binding - Asir
See http://lists.w3.org/Archives/Public/www-ws-desc/2004Aug/0007.html
Asir describes the proposal
Roberto: What about soap encoding?
Paul: Important point is to provide transition path to soap 1.2
Anish: Clarify stmnt in Q4: soap 11 binding is BP conformant
needs more discussion
[Proposal A:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0250.html]
Glen: Need to chg more things based upon version
Arthur: There are more (minor) constraints. Requirement should be
that at a minimum should be possible to describe BP 1.0/1.1
conformant services using wsdl 2.0
Glen: Sep question is should wsdl 2.0 ALSO be able to describe
non WSI conformant services
Roberto: Is version attribute an extensibility point -- so can add
new versions
Asir: Didn't consider yet
Roberto: Profiles have 2 sets of rules: WSDL description, wire
constraints. Might want to have a sep soap version for the
wire constraints
Glen: This is not a new soap version
[some discussion about the nature of the URI's defined in Proposal A]
Asir prefers Proposal A, but now presents Proposal B:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0305.html
Proposal A Pros:
Smaller SOAP 11 Binding Note
Piggy backs on Part 3, "free maintenance"
Easy migration from SOAP 11 to SOAP 12
Smaller code footprint
Cons:
Some changes to PArt 3 SOAP Binding
Proposal B Pros:
Independent SOAP 1.1 Binding Note
Cons:
New binding vocabulary, yet another
Larger code footprint
Bigger SOAP 11 Binding ?Note
Maintenance, how to issue errata against notes
Chair answers we can always republish a note to incorporate errata
Arthur: Raises issue about why this couldn't be added to Part 3
rather than as a separate note
seems like its partially political, and partly procedural
Hugo: Decouple from REC track deliverables. To support backward
compatibility -- and our charter says do it as a Note
Arthur: Proposal a is a small addition -- could we delay LC for
Part 3 to get this in
Roberto: Questions whether either proposal maintains backwards
compatibility with BP
JMarsh: Need to do more technical analysis before falling down
the rabbit hole of how to publish
DaveO: Worthy of looking at and would like it incorporated in
Part 3
PaulD: In favor of A
Asir: Sees B as being a big implementation effort
Glen: Not necessarily -- can be written to be efficient
Asir: B, because it is separate, it could diverge from the 1.2
binding
Glen: Thinks that is quite unlikely. Concern that by incorporating
into WSDL 2.0 spec, it will discourage migration to SOAP 1.2.
Maybe the differences between SOAP 1.1 and SOAP 12 may not be
quite so evident. Once we get into it, we may discover more
diffs
Arthur: Agrees bigger code footprint for B. Soap 1.1 binding is less
disruptive and encourages people to migrate to WSDL 2.0 since
they can decouple the migration decision for WSDL from SOAP
migration decision
DavidO: Having soap 11 as a separate note, then makes it somewhat
harder to use soap 11 with wsdl 20
Glen: Making it a first class part of spec does not affect ease of
use/integration
DavidO: Developer should decide on soap 11 vs. 12 based upon the
merits of soap version and that wsdl 2.0 should be agnostic.
With wsdl 2.0 hat on -- this will encourage migration to
wsdl 20 regardless of how the soap 11->12 migration goes
Hugo: Charter is clear what we have to do -- packaging doesn't
affect how easy or hard it is to use
Jeffm: Packaging discussion is irrelevant to users -- they don't
read/implement specs - they use what the vendors ship. So
lets get off the politics of the implications of the
packaging and discuss the technical issues
[hugo: "Binding descriptions for SOAP Version 1.1 over HTTP/1.1
(W3C Working Group Note), along with an implementation
report. Participants are encourage to provide implementations
of this binding." http://www.w3.org/2004/02/ws-desc-charter]
JMarsh: Yes, lets put the packaging discussion aside. If we want
to change we have to inform the AC so it can approve. Way
to do that is to produce a WD.
Arthur continues the deliverable discussion
But has been properly chastised and sits corrected :-)
JMarsh: Important issue is whether version should be extensibility
or an enumeration.
Asir: Really an enumeration, should be a string
DavidO: Wonders if we could think of the version as in some sense
specifying a profile. Combine the notion of profile and
version
JMarsh: Using the profile thing makes things more complicated with
little benefit
Glen: I should be able to put in an annotation which says what i
accept/process
DBooth: The restriction about what i do/don't should be documented
in the service def (WSDL)
Glen: It is quite likely that a vanilla soap 11 client using a
vanilla doc-lit service will most likely just work if the
service is BP conformant. So why make it have to understand
the version/profile -- seems like the wrong side of the
trade-off
DavidO: If i have spec that is constraining another spec, at some
point should have an identifier which identifies the
restricted set
[discussion wander off into profile conformance]
JMarsh: Reminds group we should be focusing on deciding between
approach A and B
Paul: Asks if can make 2 claims -- asir demonstrates no
Straw poll:
Proposal A: 8
Proposal B: 4
Abstains: 5
RESOLUTION: Consensus is to move forward with A as a "base"
[2 of the B's are concerned that is not "that simple" and that we may to
re-evaluate. B preferers are ok with investigating A]
10:30 Break ----------------------------------------
10:50 SOAP 1.1 Binding (cont.)
Back to Q2 in
http://lists.w3.org/Archives/Public/www-ws-desc/2004Aug/0007.html
[issue because soap 11 doesn't have the notion of soap module]
Hugo: Could say that to use an extension you should use a uri to
describe
It. Need to add some text to describve what we mean by using
modules
[doesn't look like security is a module -- from WSS spec]
DavidO: No problem with allowing modules in soap 11 binding
Anish: Would we provide something equivalent to notion of soap:header
so use AD feature.
[pauld: wonders how WS-I BSP describes ws-security modules:
http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0-2004-05-12.html]
Hugo: Notes the XMLP WG commented to OASIS WSS TC that they should
have
used soap 12 concepts, but the comments were ignored AFAIK
Roberto: How much of a "conceptual backport" do we really have to do
DavidO: Doesn't really "mean" anything -- ON THE WIRE - to backport
notion of modules
[Anish: http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#soapmodules
-- URI to SOAP 1.2 modules]
Glen: Purely a way to allow me use an extension in both soap 11 and
soap 12
DavidO: Essentially a way to "package" up the namespaces
Glen: Could simply use the AD feature
Igor: Thinks we need more description. Add the extra description in
6.1
JMarsh: Notes we need to make some changes to LC docs to accommodate
Straw poll: Allow soap module to be used in binding
9 in favor, 0 opposed
RESOLUTION: Allow soap:module to be used in the SOAP 1.1 binding.
Q3: need to invent URIs
Asir: Prefers use of the soap 12 naming convention
JMarsh: Any objections?
Hugo: Would like to have a "wsdl" somewhere in the uri
no objections
RESOLUTION: Use soap 12 naming convention.
Q5: should we allow the SOAP11 oneway msg exchange pattern
Glen: Suggests not using the mep attribute at all, because there
is nothing to which to map it in soap 11. Question is what
does it buy you?
[Sanjiva: Is Glen also suggesting dropping the @mep for the soap12
binding or just for 1.1? if only for 1.1 I'm +1 for it;
I agree that soap11 doesn't have a mep concept in it.]
[just for 1.1]
Glen: Does not want to drop for 1.2 -- wishes for a better way to
assoc wsdl and soap meps, but thats a different dream :-)
Glen: When verison is 1.1 the mep attribute can be safely ignored
Sanjiva: Asks if we will keep the protocol attribute
[suggestion to use the wsdl1.1 transport attribute -- see Q3]
Glen: Either disallowed (fault) or ignored are the 2 options
[3rd option: continue trying to figure values to use]
[Sanjiva: I suggest we disallow the use of @wsoap:mep .. that's a
soap12'ism and it'll be confusing to have it there. ]
Straw Poll: whether to invent uri's for meps
the NO's have it by a landslide
Straw Poll: fault if it appears or just ignore
Fault: 0
Ignore: 5
Abstain: the rest
Consensus is ignore
[sanjiva: hey my vote was +1 for faulting ..]
[sanjiva: oh well; I lost anyway.]
RESOLUTION: Ignore @wsoap:mep.
back to Q4: what is relationship between soap 11 binding and BP
[Sanjiva: Looking at that question - it may be useful to alllow a
*single* binding to describe both soap12 and soap11/bp1.0.
(esp. since we've dropped @style .. so we've effectively
cut off rpc/lit from BP/1.0 already)]
Glen: What if somone wants to provide both soap 11 and soap 12
at same endpt and use the same binding
[that issue is independent: renamed to Q6]
JMarsh: Can put a conformance claim into wsdl--describes the
conformance of the wsdl
[discussion of why should this WG define such a claim]
[Sanjiva: I can't hear everything but my pref would be for the
wsdl2 defined soap11 binding to cover soap11/bp1.0 scope and
not beyond. That is, we don't need to support soapenc and
all that stuff.]
Pauld: We decided earlier you can make conformance claims against
the wsdl doc, but you could add additional constraints on
what is allowed on the wire
Glen: Question is how to express the additional constraints
without breaking a client that actually respects those
constraints but doesnt "understand" the constraint URI
Anish: Maybe we should generalize this concept
[back to the packaging discussion]
[Pauld: Suggests packaging is uninteresting -as the note could be
"see part3"]
JeffM: The argument is that the target of this "soap 1.1" binding is
not really soap 1.1 but the version of soap defined by the
ws-i BP: call it soap 1.1prime
DavidO: Another way to think about it is that their is a "list" of
specs which are constraining the messages. We could list all
the specs, or we could wrap them up into one uri.
Disadvantage
of the one uri approach is that you would have to "understand"
the new "one" uri, even though you already understand all the
uri's that are being wrapped up. Hence limits its usefulness.
Thinks there is an implicit wildcard in the charter.
GlenD: Thinks we should follow the charter and do a soap 1.1 binding
and keep profiling separate
DavidO: Should do the profiling thing because others (wsi) will do
it
Pauld: We (BT) take the wsi profile and make it work :-)
JeffM: Maybe rather than doing the soap 1.1 binding is that we should
do the soap 1.1 prime binding
[Roberto: +1]
Anish: wsdl already has facilities to indicate what pauld wants to do
12:30 Lunch ----------------------------------------
Scribe: DOrchard
13:30 SOAP 1.1 Binding (cont.)
DavidB: BP does a refinement of soap 11. A bp service might not
be compatible with soap 11, ie it is incompatible.
GlenD: Everybody agrees bp is important. Does soap 11 binding allow
non-bp profile? If say full soap 11 and yet want to say bp,
then 2 decisions: is soap version(or some other name) used for
bp or an extension/
[GlenD: Cheap proposal - we could use an attribute/marker on the soap
1.1 binding to indicate rpc/encoded. This would entail
MUST-ing the rpc style... It would obviate the need for
things
like the WSDL 1.1 "namespace" attribute, since the NS is in
the
schema. The standard rpc-style schema restrictions would
apply.
And arrays would be indicated in the WSDL-1.1 style (deriving
from SOAPArray, etc).
[Roberto: They told him don't you ever come around here
Don't wanna see your face, you better disappear
The fire's in their eyes and their words are really clear
So beat it, just beat it.
[GlenD: The idea of this would be to support RPC encoded legacy
services.
Oh sorry. one more thing. The schema would be understood to,
since it's encoded, represent a structural description, but
not
a validatable one. I.e. use the WSDL 1.1 type mapping, which
says any given element might be <foo>content</foo> or
<foo href="#c"/>]
Jacek: Can't put this in the spec as "close" to normative because of
schema language around what "encoded" means.
Glen: We would add a style all the way down and define a style.
Paul: What is the implication of saying that the message part is
encoded?
Glen: Not defining new schema language, it's a different
interpretation of schema.
Paul: Would like to take existing services and describe in wsdl
2.0...
Can't take any old schema and say "is rpc" or "is encoded".
You are doubling the # of tests.
[why?]
[GlenD: The interpretation == the schema, rather than describing an
infoset to be used for validation/serialization, describes an
infoset which is used (structurally) to build a SOAP data
model, and *that* is what gets serialized]
Paul: Have to put service in rpc/lit, rpc/encoded.
[some discussion about rpc.... ]
[GlenD: This is, although interesting and potentially useful for
legacy apps, primarily an intellectual exercise. If it could
be done, that would be nice, but the potential problems may
indeed be too great.]
Paul: Want to deprecate encoded.
[GlenD: Nothing is being proposed. This is just discussion.]
Marsh: There's 3 proposals: support 1.1 fully, support bp only soap
1.1,
and ?
Jacek: Propose to cut whatever bp cuts. And that we don't have to do
work to cut
Strawpoll question: limit wsdl 2.0 to BP 1.1 subset of soap 1.1
Glen proposes: OR soap 1.1 support at level of soap 1.2 support, ie drop
encoding, don't say anything about charsets.
[Roberto: soap 1.1 minus encoding vs. bp 1.0]
[Lots of people ask about bp 1.1 versus bp 1.0. Do we need to talk
about which version of bp...]
[discussion about encoding..]
Roberto: For encoding, can have either href or value. Encoding some
times <element xsi:type="xsd:int">100</element>, but this is
illegal because type is an attribute and not allowed on
complex types
[lots of people disagree]
Roberto: Using xsi:type is discourage
Strawpoll:
Limit to bp 1.1 subset of soap 1.1: 3
Limit to soap 1.1 minus encoding: 11
Next question: How do we indicate bp 1.1 conformance.
First option:
<binding version/profile/spec="soap11uri bpuri"/>
Second option:
<binding version="11uri" wsi:profile="bpuri" bt:profile="bturi"/>
[JacekK: what is bt:profile?]
Anish: Can't really mark wsi:profile as required, could to as
elements.
[Pauld: A subset of the WS-I that interoperates :-)]
[Helen: Question: in option 2, is there an assumption that bt profile
is
a subset of wsi?]
Second option part 2:
<binding version="11uri">
<wsi:profile wsdl:required="true">bpuri</wsi:profile>
</binding>
Marsh: Convenience of #1 is providing semantics and relationship
between uris. Exact relationship is?
[relationship is union of constraints]
[dbooth: (And presumably all constraints must be met.)]
Anish: Wsdl 1.1 encoding attribute on binding had list of URIs (ie
soap encoding). Caused interop problems.
[Asir: here is the link to SOAP 11 encoding style issue -
http://lists.w3.org/Archives/Public/xml-dist-app/2001Oct/0330.html
the one mentioned by anish]
[Pauld: Points out that style is an unordered list of URIs]
[Sanjiva: Are we seriously considering binding/@version??? That's ugly
because that gives the sense that that's the version of the
binding and not of the binding namespace in use!]
[Asir: mm .. nope, we are not considering binding/@version attribute]
[sanjiva: thanks :)]
[Asir: Sanjiva, that binding/@version is a typo]
[sanjiva: ok .. but its in the minutes repeatedly without a correction!]
DaveO: BT can control that the clients must understand bt:profile to
talk to BT.
PaulD: This can be constraint or additional information.
Glen/marsh: these 2 are very similar
Paul: Likely to have only 1 profile in play
Davidb: More than 1 profile
Daveo: WS-I doesn't care about the marker from extensibility point
of view. The BT should care though.
GlenD: All required extensions are effective in conjunction.
[asir: in UK, BP is an acronym for British Petroleum]
Pauld: It's easy to say something occurs never or once, once we
allow more we gotta go into combinations.
RESOLUTION: The version attribute won't indicate profiling.
Q6: single binding for single binding for soap 11 and soap 12
Asir: Proposes wsoap:version="1.1 1.2"
[Now to question 6: should we have a single binding for 2 soap versions]
[GlenD: Actually it's: *can* we have a single binding instance for
both soap 1.1 and soap 1.2]
Asir: Bit of a problem with wsoap:protocol. wsoap ns is soap
version specific. Need soap ns that is version agnostic?
Glen: Right now, asir's suggestion is to invent a value for protocol
for alsjkdflkfjsdlgasfdlhkda;slkjfsdalk
[igors: I think it should be
<service>
<endpoint binding="mySOAP11" address="abc"/>
<endpoint binding="mySOAP12" address="abc"/>
</service>]
Marsh: We define 1 value for protocol for soap 1.2, potentially
another
for soap 1.1. This is syntactic shortcut for 2 bindings.
Strawpoll: consider supporting both soap versions in a single binding.
Hugo: Very special case. Can have other protocols.
Asir: If this is true, do we need to support soap 1.1 soap 1.1
binding note?
Paul: Need to support 1.1 only.
Roberto: Creates more problems than it solves. what does ws-i profile
conformance inside the binding?
Marsh: Anybody a champion of this?
no.. [moving on to better things.]
Marsh: We will describe the changes to part 3 as lc comments, and
also
do changes to soap 1.1 note. We agreed to do a soap:version
attribute in part 3.
Asir: About 3 weeks until note is released...
15:30 Break ----------------------------------------
15:50 RDF Mapping
- Overview from Bijan, Q&A, discussion about next
steps.
http://lists.w3.org/Archives/Public/www-ws-desc/2004Aug/att-0018/2004-Ju
ly.ppt
http://lists.w3.org/Archives/Public/www-ws-desc/2004Aug/att-0019/RDF.pdf
Bjian: Want to enchance wsdl with semantics.
Davidb: Also want to integrate wsdl with other kr systems
Bjian: swsl will be the merge of wsmo and owl-s and be usable into
wsdl.
[Bijan goes through slides.]
[Pauld: Notes the collective noun for OWLs is 'stare' or 'parliament']
DavidB: The infoset is an abstraction that represents meaning of
physical representation. WSDL has a component model that
represents meaning of infoset. Model the component in rdf
choice is a direct transliteration of component model into
rdf.
Bijan: Owl doesn't use schema types because they use URIs and there
aren't URIs for the schema types.
Asir: Schema/Jeremy Caroll from semantic web are looking at the
SCUDs for doing URIs for user defined types.
-----------------------------------------------
ISSUE 252 - syntax of media type annotation
Umit: Schema api as w3c note, no support for additional attributes,
but there is support for annotations.
Glen: Attributes are defined within the appinfo
Asir: There is getAnnotation string. Returns text representation of
string. This means ?
[asir: link is at
http://www.w3.org/Submission/2004/SUBM-xmlschema-api-20040309/xml-schema
-api.html#Interface-XSAnnotation]
[GlenD: We don't know that this API is even adequate for <appInfo>!!!]
[Asir: Look at annotationString]
[Roberto: ATTRIBUTES ARE ANNOTATIONS]
[GlenD: Schema annotations CONTAINS attribute extensions. They aren't
different things. They aren't different things. They aren't
different things. They aren't different things.]
[asir: +1. +1. +1.]
[Roberto: There are NO "schema extensions" whatsoever]
[asir: +1]
[can somebody sumarize this?]
Glen: Working group preference is attributes instead of appinfo.
Marsh: Close issue 252 by adopting an attribute based syntax, put in
an ednote that an attribute annotations might not be exposed
by schema processors.
RESOLUTION: Close issue 252 by adopting attribute based syntax, add
ednote
that attribute annotations might not be exposed by existing
schema processors.
[sanjiva: I'm going to drop off ... if there's a discussion of
publishing
a WD of the RDF mapping, I'd like to request some time to have
the work reviewed by interested parties in IBM. Several groups
have expressed interest in it and so we need some time to
review and develop our positions. Thanks for considering
that!]
Glen: Send to soap builders
ACTION: Glen to send a message about the mediaType annotation
(attribute/appInfo) to soapbuilders.
Asir: Few implementations of 7 schema apis support annotations.
Marsh: Rolling in these issues should get to last call for media
types
document.
17:00 Adjourn
Received on Tuesday, 24 August 2004 19:16:37 UTC