- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Tue, 16 Nov 2004 12:43:10 -0800
- To: <www-ws-desc@w3.org>
Web Service Description Working Group
Minutes, FTF meeting 9-11 November 2004
Sunnyvale, hosted by webMethods
Agenda:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0023.html
Attendence:
David Booth W3C
Allen Brookes Rogue Wave Software
Roberto Chinnici Sun Microsystems
Glen Daniels Sonic Software
Youenn Fablet Canon
Hugo Haas W3C
Anish Karmarkar Oracle
Kevin Canyang Liu SAP
Jonathan Marsh Chair (Microsoft)
Arthur Ryman IBM
Jerry Thrasher Lexmark
Sanjiva Weerawarana IBM (afternoon)
Umit Yalcinalp SAP
Prasad Yendluri webMethods, Inc.
Phone:
Paul Downey British Telecommunications
Jean-Jacques Moreau Canon
David Orchard BEA Systems
Regrets:
Tom Jordahl Macromedia
Dale Moberg Cyclone Commerce
Mark Nottingham BEA Systems
Bijan Parsia University of Maryland MIND Lab
--------------------------------------------------------
Tuesday 9 November
--------------------------------------------------------
09:10 Introductions and logistics
- Assignment of scribes
Youenn Fablet, Glen Daniels, Asir Vedamuthu, Arthur Ryman,
Sanjiva, Kevin Liu, Allen Brookes, Hugo Haas
Scribes: Glen, Allen, Youenn, Arthur, Hugo, Kevin
Scribe: GlenD
- Agenda bashing
Various scheduling shuffles may/will be made
--------------------------------------------------------
09:25 Scheduling of deliverables
- WSDL 2.0 (January CR?)
- Primer (Dec WD?)
- SOAP 1.1 Binding
- Assigning Media Types Note (Jan?)
+ Tracking Last Call issues: ExIT? WG issues list?
Jonathan: Over 150 issues, so far dealt with about half (mostly
editorial).
Still have quite a bit to do. No way to finish everything at
this
meeting, and with the holidays it seems unlikely we'll close
all
issues until at least Jan F2F.
David: Do we have to resync with the charter schedule?
Jonathan: That's what we want to discuss - we got a lot more comments
than expected. Let's see how we do at this meeting and then
decide if we need to take action (longer concalls, task
forces,
delegation, etc). CR in Jan is 3 months off charter
schedule.
This is within the window before we'd need to explicitly ask
permission to slip schedule. As of today we're (barely) OK.
Grace period expires in January.
Primer discussion.
DBooth: Some good comments have come in.
Jonathan: At some point we need to ship it as a WD...when?
DBooth: December seems reasonable
Jonathan: Date would be good to stake down, but shouldn't slip
again....
DBooth: mid-December
Jonathan: Don't want to have probs with moratorium
DBooth: 15th-20th
SOAP 1.1 Binding
Jonathan: Hope that's getting close. Maybe we can publish soon after
this
meeting. One or two WDs, then LC, get comments, refine....
Assigning Media Types Note
Jonathan: Some issues have come in, need discussion. If we have time
this
week maybe we can hit these, but rather devote an entire
telcon
to that sometime soon. Hopefully finish (final or 2nd LC) in
Nov/Dec timeframe.
Umit: Want an example
Jonathan: Yup, that seems editorial. As a note, we don't need to use
the
whole mechanism for tracking comments that a Rec-track
document
needs. Propose using existing issues list and tracking
there...
what do people think?
(general nodding of heads)
(brief discussion of RDF mapping - would have been nice to have a draft
by
now)
--------------------------------------------------------
09:35 Editorial issues
- Propose to refer Issues 74g [2], 78 [3] to editors
[2] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC74g
[3] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC78
Jonathan: Lots of tweaks from MS - left it in Word format for now.
Jonathan: OK to delegate these to the editors?
(nod nod nod)
--------------------------------------------------------
09:40 Issue LC5f: QA Review on WSDL 2.0 Part 1, intro and conformance
issues (f) [6]
- Roberto's proposal [7]
- Further list of errors from Roberto [8]
- David Booth's suggestion for dropping Processor Conformance [9]
- Additional facets to this issue
+ Some "errors" will be trumped by "fatal errors"
+ Processing model needed?
- related issue LC75v [10]
[6] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC5f
[7] http://lists.w3.org/Archives/Public/www-ws-desc/2004Oct/0027.html
[8] http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0008.html
[9] http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0015.html
[10] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC75v
Related issue
http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC75v
Roberto: Too much interpretation necessary right now, so we need to
add something per my proposal. David pointed out that my prop
gives almost carte-blanche to a processor - might need
tweaking.
DBooth: Are we trying to define the ability to partition the doc into
processed and not processed stuff? Or are we going to simply
not say what it means if there's a portion that's undefined?
Roberto: Pretty easy to define what parts a processor does not
understand. If you encounter an optional extension which isn't
understood, then you don't understand that particular element.
If you encounter a mandatory extension which is not
understood,
then you don't understand the enclosing element.
DBooth: This comes up in two places - open content extensions and F&P.
Same wording, essentially.
Jonathan: We're debating this because we wondered if we need two classes
of
errors. If we add this, does that change?
Roberto: This implies we can get rid of the processing model. Still
requirements, like understanding Schema 1.0, but runtime
behaviour description can go.
Jonathan: Why mandate schema conformance, and why support XML 1.1? Maybe
we need a profile section? Grouping specs (schema, wsdl, etc)
together as an interoperability marker is different than
saying
"all processors MUST do all these things"
Anish: Don't understand why you wouldn't need processor conformance?
Didn't you just have text which describes what a WSDL
processor
does?
DBooth: This is add'l explanation - intended it as a note, not a
formal
part of the spec.
Jonathan: Formal part describes extensions in terms of doc semantics,
not
processor behavior.
Roberto: Are you (DBooth) suggesting removing the term WSDL Processor
from the spec?
DBooth: Notion of processor not necessary for conveying the meaning of
a WSDL document. Be good to explain it clearer, but that can
be
in a note. Still leaves open the question.
Roberto: Term "processor" ok, but shouldn't define runtime behaviour
Anish: Still defining rules, right?
Jonathan: Two levels of conformance - doc and proc. Doc conformance is
testable. Proc conformance was tricky - included extension
understanding and schema version compatibility.... trying to
work this out.
Arthur: Each document must be understood in the context of a certain
processor. So could be valid or not valid depending.
Glen: +1. You don't have to describe it as a processor per se, could
just be a "universe of understood extensions".
Jonathan: Can say that a processor is interpreting a document in the
context
of a universe of known extensions
DBooth: Validity is independent of processor. Doc is either good or
bad.
But if you don't have access to the extension specs involved,
you
can't tell.
Roberto: Can define which parts of validity depend on the external
world.
Jonathan: we can define the semantics of mandatory extensions in terms
of
doc conformance. So do we still need the concept of processor
and processor conformance?
Arthur: So it's really a triple - document, known extensions, and the
set of stuff the processor wants to process. Testing a
processor
for conformance is giving it 1) a doc, 2) a list of known
extensions, and 3) a subset of the doc to process. A
conformant
processor seems to be one that takes good (non-garbage) input,
extensions that it knows about, and a subset of the doc to
look
at, and correctly reacting to the set of mandatory extensions
(i.e. fault on unknown ones)
Jonathan: So success is undefined (depends on processor), but we can
talk
about failure?
Arthur: Right.
DBooth: Arthur has is exactly right, but that's not a path I want to
go
down.
Arthur: Hard to test this...
DBooth: Simpler way to deal is to say that if a processor attempts to
process a portion that is undefined, it should fault.
Roberto: Or you can say processor doesn't process stuff it doesn't
understand. So we can say "processor MUST not process..."
instead of "processor MUST fault..." - leave it undefined
after
that. Specifying errors is hard (cf recent discussion)
Jonathan: If we remove proc. conformance, and definition of processor,
call
everything an error, add text as proposed for interpreting
mandatory extensions, what's the missing piece?
Anish: How can you get rid of the concept of processor?
Jonathan: You just say it's an error to have a non-conformant doc.
Anish: You are defining a processor as soon as you say there's an
error.
Roberto: A processor is an agent with a lifecycle, etc... we can just
define a bag of stuff, some of which is understood and some of
which isn't.
Anish: That is a processor, even if implicitly.
Roberto: It's about document semantics.
Arthur: You don't have to call it a processing model, but it is
Jonathan: So we need to either punt processor entirely, or make it more
crisp.
If we remove processor conformance section, perhaps we don't
have
to remove processor definition?
Anish: Why get rid of it? Hard to test?
Jonathan: This is all about trying to unify the types of errors
DBooth: Issue with classification of errors is about trying to say you
could recover from some errors. Could elimate some of the
rules
in the proc. conformance section by focusing on document
conformance instead...
Arthur: Problem one is defining what wsdl:required means. Problem two
is about interoperability (XML 1.0, Schema 1.0, etc)
Anish: Like the idea of a profile section, could help with interop
DBooth: Problem one is already solved.
Jonathan: Not sure everyone agrees... Are we trying to stop
implementors
from doing silly things, or just more crisply define the
rules?
Arthur: Easy to test the extreme POV "if there's a non understood
required extension in the doc, you fault" that's easy. Once
you
introduce this "subset" of processed stuff that's harder.
Anish: Our test suite can talk about this. J2EE/.NET guys can define
tests in more concrete terms (generate stubs, etc)
Jonathan: If we say a WSDL processor interprets a WSDL document in
context
of the task it's trying to perform (the subset) and a list of
understood extensions, do we still need processor conformance?
Arthur: Yes, because that's what the fault-on-misunderstood test is
about
Jonathan: How to move forward on this?
DBooth: We need to be in sync about document validity. Three possible
outcomes when checking validity on a doc with a req'd
extensions.
1) extension is valid, and doc conforms.
2) extension is valid (known), but doc doesn't follow the
rules,
and 3) indeterminate (you don't know the extension).
In terms of processor conformance, we want a processor in case
3
to halt/error.
Arthur: Need to define what a processor does with good input, and with
bad input. Already said processor doesn't have to validate
documents. Let's assume good input.
Glen: Like the dichotomy between doc and processor conformance. This
is like the SOAP processing model, and conformance is
determined
by the test suite and the rules/extensions therein, not just
the "raw" processor. We should be defining extensions for our
test suite, like SOAP did.
Arthur: 1) is doc good (doc conformance) - spec should let us make
that
call, 2) semantics of bindings (take a WSDL, take a wire
message,
and ask if the message conforms to the binding rules), 3) bags
of messages conforming to WSDL MEPs. All these are testable.
Grey area is processor conformance, which involves required
attribute. Best we can do is giving the triple (doc, extension
universe, subset) and go from there.
Roberto: Doesn't have to fail - just correctly determine whether it's
understood.
[uyalcina: +1 ]
DBooth: #1 isn't quite testable. Test suite may be given a doc which
it
can't determine the conformance of.
Arthur: No, because the doc is part of the test suite and we define
the
context in which it is interpreted.
DBooth: Gotcha.
(trying to reign this in and figure out how to move forward)
DBooth: Enough to say processor should fail if it attempts to process
a
portion of the document it doesn't understand
Arthur: Could easily define a rule for a conservative processor, which
would just fail if there were ANY required extensions that
were
not understood in the whole document.
Jonathan: Don't want multiple "classes" of processor
[dorchard: I'm soo confused about what is being proposed.]
Jonathan: Can we just make this a "strongly recommended"?
Glen: Yes, just say that WSDL is typically about communicating with
Web Services. If you expect that communication to work, you
had
better damn well understand everything that is required in the
portions of the WSDL you're using.
Umit: Let's retain processor conformance, if it's not crisply
defined, that's bad. A WSDL has a required soap:module - if
there's no REQUIRED error if not understood, you cannot tell
what happens.
(discussion of how/if to report errors, and potentially how to specify
the
subset of the doc is being processed)
DBooth: In Umit's example, the processor attempts to send messages
after
doing things it shouldn't have (processing a doc with a
misunderstood mandatory extension). Thats a gamble.
Anish: No point in talking about non-conformant procesors. But we can
talk about conformant ones.
DBooth: Key is talking about meaning of document wrt the extensions.
Anish: I'd rather the model were more explicit.
(discussion of processing model)
DBooth: So you've just shifted the "wiggle room" from the word
"should"
to the word "processing"....
(i.e. its undefined what "processing" means)
11:05 Break ----------------------------------------
11:30 Resume
Jonathan: OK, two options. Keep processor conformance section as is, or
remove it and put in some kind of strongly worded advice to
developers about dealing with extensions. In both cases, only
one class of error (remove "fatal"). Is that basically the
question?
DBooth: Two suboptions on second option - strongly recommend, or (as
Anish says) say MUST, even though you don't nail down what
"processing" means precisely
Roberto: Smaller spec is better.
Jonathan: So option 2
straw poll:
Option 1 == keep processor conformance
Option 2 == get rid of explicit section, and move content to other
bits (TBD after this poll)
Option 1: 3
Option 2: 9
Glen: Could define proc conformance as simply building the component
model.
[dorchard: For the formal record, BEA objects to not having processor
conformance.]
Arthur: Hard part is determining what the subset that you're
processing
is
Glen: You define that subset for the particular tests in the suite,
not in general - just like SOAP model of what's understood
Roberto: We can't actually test anything but wire stuff (messages,
MEPs).
Beyond that, what good does it do to talk about conformance?
DaveO: SOAP is about a model/infoset.
Roberto: The important part is that the participating nodes DO things
that are conformant with the description+extensions
[kliu: big +1 to Roberto]
Glen: I want to be able to complain to people who build products
that don't fail on wsdl:required things that aren't
understood...
Jonathan: Market deals with that, right?
DaveO: I'd like to fail early - when building the component model
Arthur: why not use the conservative model and just fail on ANY
un-understood required extension
Glen: That would disallow multiple bindings
(discussion of meaning of document with respect to extensions in
various places - is it OK for a lower level extension to affect higher
level (or parallel) components)
Kevin: Talking about the client...
Glen: No no, both sides
Roberto: It's currently about the client/requestor only....
(look at the spec, indeed it is)
Glen: Yikes! Fix that immediately!! What about skeleton building?
[uyalcina: Glen goes on to describe the number of processors that exist
out there...]
(scribe was talking about differences between client and server
perspectives on a WSDL)
Daveo: Why can't we treat this like XML? An editor that reads in a
malformed XML can still put stuff up, that "looks like" an
XML doc. So it "stopped processing" the XML-like part, but
still continued to be a useful editor. Can we do the same
for WSDL? Let's talk about conformance from the component
model perspective....
(discussion of whether extensions affect the component model, or just
appear in them)
Jonathan: Can we table this for now?
Glen: What about a next AI? And what about the client/server
problem?
(discussion of telling people explicitly that services have to
implement WSDLs faithfully - clients can pick and choose, servers must
do everything)
Jonathan: At this point, how do we move forward?
(discussion of building component model as the main task of a processor
vs. a broader scope)
Jonathan: So we have the same two choices as before, plus a third one
about defining conformance in terms of a processor building
the correct component model
DBooth: If we talk about the component model as conformance, we still
need to define the meaning of the document, independent of
who's processing it and why
Jonathan: Looking for AIs to get concrete proposals for these three
avenues
ACTION: DBooth and Roberto to describe option 2 (remove definition of
processor conformance, write up clear guidelines to
developers)
ACTION: DaveO to work on text for option 3 (redefining conformance in
terms of building the component model)
No one steps forward to take an AI for option one....
[Marsh: Potential issues to revisit:]
[Marsh: 1) Is it clear that a server must implement everything it's
description says it does?]
[Marsh: 2) Un-recognized required features result in components,
un-recognized required element-based extensions don't. Why the
difference?]
12:45 Lunch ----------------------------------------
Scribe: Allen
--------------------------------------------------------
13:40 Issue LC49: Clarify whether Parts 2 & 3 MUST be supported [11]
[11] http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0015.html
Jonathan: Proposal, 8.3 refers to part 1
Umit: Just saying part 1 isn't going to be clear enough, it will
still depend on MEPs.
DBooth: Parts 2 and 3 both define extensions. Are they required
extensions?
GlenD: Do we need to make it explicit that it is only part 1?
Umit: Problem with 8.1 as well.
Jonathan: Document that uses an extension must follow rules of that
extension. Do we need to do anything other than clarify
part 1 only? Not clear whether there is an issue with 8.1.
We should deal narrowly with the issue (8.3).
Umit: Replicate any language that says part 1 from 8.3 to 8.1.
Jonathan: 8.1 seems to say that you have to validate against all
appropriate schemas, not just the schema for the wsdl
namespace. In order to have a conformant document you
have to have all the necessary schemas.
Arthur: The document is either good or bad whether the processor
can find the schemas or not.
Jonathan: Hard to test though.
Arthur: To conform a document needs to conform to all relevant specs
including those referenced. Do we define what it means to
define an extension? An extension definition needs a namespace
and a spec.
Anish: 8.1 only says that a document needs to be validated by wsdl
schema.
Arthur: Conformance is not just validation.
Anish: Fix to remove "family" from last sentence and move it to the
end of the sentence.
Jonathan: Proposal is to move "family" to end, and add a conformance
section to each of the bindings.
Arthur: Should be a paragraph that says what an extension is, also
a statement that says that an extension needs a namespace
and a spec that says what conformance means.
Jonathan: Friendly amendment: add sentence defining extension as Arthur
asks.
Hugo: Did we already have this and move it to someplace else?
Jonathan: From issue 5b, moved from a table not from this section.
[Marsh: An element information item whose namespaces name is "...wsdl"
and whose local part id definitions conforms to this
specification if it is a valid according to the XML schema
for that element as defined by this specification (uri to
schema) and additionally adheres to all the constraints
contained in this specification family and conforms to
the specifications of any extensions contained in it.]
[Marsh: + add conformance sections to each of the bindings.]
[Marsh: + 8.3, clarify that "this specification" means Part 1.]
Anish: Extension specs must say what it means to conform. Propose
that extension specs must have a conformance section.
Jonathan: Do we want to constrain or provide advice to extension
writers on how to write extensions? In particular, a
conformance section.
Added to the proposal.
[dorchard: +1 to adding the text in]
[Marsh: + adding a note advising extension specification authors to
have a clear statement of conformance.]
Issue 49 closed with above resolution.
--------------------------------------------------------
14:25 Issue LC54: WSDL Last Call issue (@compatibleWith proposal) [4]
Last discussed at FTF [5]
[4] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC54
[5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Aug/0056.html
DaveO: No way to know with interface extension whether extension
is compatible, or simply using stuff from extended interface.
Backwards compatibility, does extended interface still
provide extended interface so that it is still usable in the
old way.
[uyalcina: Is compatibilty you are talking about wrt behavour of the
interface's implementation not about type compatibility,
right?]
DaveO: Example, payment service extending book service but changing
notion of book service.
Roberto: (clarification) book service for getting free books, extension
adds payment service, old methods still do what they did
(free books) but adds other methods as well.
DaveO: Just an indication of whether extension is compatible.
[pauld: AIUI it's a communication of a semantic, but a very important
one: that the new interface is *intended* to be backwards
compatible with the old one.]
Umit: Many notions of compatible.
[GlenD: paul: Do we need this in Java, too, then? If I write a class
Foo extends Bar, I fully expect to be able to use Foo as a
Bar, period. If additional semantics are now required, you've
broken the Bar contract. You can do that (express the
INCOMPATIBILITY) in WSDL using a required extension.]
Umit: DaveO's compatibility requires that behavior needs to be
compatible, not just messages.
[pauld: Java is typically deployed in closed systems, so big-bang
configuration management is typically possible.. but i guess
Java would benefit from some better means of communicating
when compatibility is broken.]
GlenD: Our version of extends should be the same as programming
language, should honor the contact.
[dorchard: Paul, the RMI scenario is problematic for this as well.]
GlenD: We don't talk about semantics of an interface. This proposal
specifies the semantics.
[pauld: I guess we're looking for something less tightly coupled
than Java code .. ]
Roberto: Should we split proposal further. Reserve extends to what
GlenD says is compatible (syntactically). Define attribute
which specifies symantic compatibility.
Sanjiva: Already the same as Java, can use the base interface but
behavior may not be the same as another implmentation of
the same interface.
[uyalcina: +1 to Sanjiva]
Roberto: Microsoft LC comment on safety (75c) tooling can't set
property,
users won't set it either. Same is true for compatibility.
[Marsh: car insurance inherits from contact updates]
[GlenD: class CustomerThing { operation updateContact() }]
[Marsh: car insurance overrides contact update - is it compatible?]
[GlenD: class CarInsurance extends CustomerThing { operation
submitClaim() }]
[dorchard: Kevin, did that help?]
DaveO: If customer can't interact with CarIsurance as a CustomerThing
in the same way that they could with something that is only
a CustomerThing then it is incompatible.
[dorchard: Class Foo exists. Then FooMetadataExchange interface extends
Foo by adding in MetadataExchange.]
Sanjiva: Providing more semantics for an interface is not a good idea.
Defined operations are not the only things that can be done
with a service.
Roberto: Do those that object to compatibility at the interface level
also object to compatibility at the service level?
[dorchard: So something like Service A' deploys FooMetadataExchange and
is compatible with Service A that deploys Foo]
DaveO: Not semantics, just a flag that says that software doesn't
have to change since the operations still do the same thing.
[Anish: It seems to me that this is about semantics in the same sense
(as Roberto pointed out) that 'safe' is about semantics]
[uyalcina: +1 to Anish]
[Roberto: about semantics, therefore untoolable]
GlenD: Default should be that extensions don't change operations in
extended interface. Better to add indication that extension
does change operations.
[Anish: So the question is -- is wsdl only about tooling?]
[uyalcina: the interfaces are only about messages exchanges and type of
the messages. Extension can only tell you what kind of message
exchanges are inherited, nothing more nothing less. ]
[Anish: I would agree with that, but for the existance of 'safe']
[pauld: Sees "compatible" more akin to "required" than "safe"]
[kliu: +1 to Umit]
GlenD: what if you add extension, such as a feature, to an operation
that requires credit card? This is incompatible.
Anish: Example, service S1 and service S2, S1 has endpoints with e11,
binding b11, e12, b12, S2 has e21, b21, e22, b22,
interfaces I1, I2 I2 extends I1. If compatibility is defined
at service level then you can't talk about compatibility only
at interface level.
DaveO: Namespaces are about semantics but you can talk about
namespaces without talking about semantics.
GlenD: To change to non-compatible one can add extensibility to
indicate non-compatible behavior.
[Anish: DaveO: would it be correct to say that what u want is -- when
using 'compatible' interfaces in addition to the having the
same message formats etc (that extends allows u to do), the
two interfaces mean the same semantics (for the inherited
operations). What the semantics mean -- go ask the interface
writers. Or did i get it wrong in spite of you repeating what
semantics mean 15 times]
DBooth: Meaning of a message is defined by the namespace of the
message
itself not by the WSDL document.
[dorchard: sorry Anish, trying to track DavidB]
[Anish: np]
Roberto: Useful notion of compatibility is whether I can continue to
do what I was doing. Looks like it will be too complicated
to indicate compatibility. Not enough to just have a flag.
[dorchard: Anish, that's fairly right. It's that the client can use the
new interface as if it was the old. ]
Sanjiva: A way to get what DaveO wants, use XInclude.
[Anish: k, thx]
[dorchard: what word would be used?]
GlenD: Can use an extension to get what DaveO wants.
Roberto: Cost of extension is higher than just a flag.
GlenD: What if interface doesn't do what flag says?
[Marsh: Are there objections to rejecting the proposal for
@compatibleWith]
DaveO: Objects
[pauld: I support this proposal]
GlenD: Any object to tightening up wording around extends to do the
same thing.
DBooth: If adopted, will this take us back to last call again?
GlenD: Resolutions to formal objections will take us back to last
call, unless there is no change.
DaveO: BEA will go as far as possible to highlight that versioning
must be dealt with.
[pauld: WSDL 2.0 should say *something* about versioning]
GlenD: Wsdl doesn't say anything about behavior of operations with
extends, just that it is presumed that behavior of operations
is the same across extension.
Hugo: No concensus that we should solve this problem.
Anish: Should first attempt to tighten up extension text before
doing formal vote.
Roberto: We don't define what extends means. We have two requirements
on versioning.
Jonathan: We can define and extension, not in the core, that can be
used to indicate compatibility.
GlenD: There are a lot of kinds of incompatibility. Can indicate
each with you own type of extension.
Jonathan: Client getting new wsdl will break because of the new
feature. New client will break as well.
GlenD: Not a problem since the feature is required to use the
service, not just about compatibility.
Jonathan: Extra work for the processor to deal with a feature with
wsdl:required.
ACTION: DaveO will recast the proposal using an extension namespace.
16:00 Break ----------------------------------------
--------------------------------------------------------
16:20 Issue LC29b: Review of WSDL 2.0 Pt 3 Last Call WD (b) [15]
Issue LC18: Relationship between Features and SOAP Modules ?? [16]
- Awaiting Glen's action
[15] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC29b
[16] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC18
Still waiting for Glen's action
--------------------------------------------------------
16:20 Application Data Feature issues:
- Issue LC76d: WSDL 2.0 LC Comments (Part 2) (d) [17]
- Issue LC24: "ad:mustUnderstand" - ?? [18]
- Issue LC48d: XMLP Review of WSDL 2.0 Part 2 LC WD (d) [19]
- Issue LC53: Optional predefined features in Part 2 [20]
- Issue LC61f: comments on the wsdl 2.0 working drafts (f) [21]
[17] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC76d
[18] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC24
[19] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC48d
[20] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC53
[21] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC61f
LC 76d, proposal to remove AD feature.
LC 24 (wait for Asir)
LC 48d: Is this example not compelling or did XMLP miss the point?
Jonathan: Example is a kind of versioning. Add new data without
changing schema for body.
Umit: Others are confused about ADD vs soap:module as well.
Jonathan: Example doesn't explain why data is being added.
ACTION: GlenD and DaveO will add new text to AD example to
explain why additional data is used.
GlenD: AD fixes data that goes into the message. Soap:module does
not.
Sanjiva: There is no feature in the example is it incorrect?
GlenD: Example is correct but would be better with a feature
declaration. Example is supposed to have existing
interface that is being changed. The example doesn't.
Can't change the operation but can change the binding.
AD feature can be used to extend XML types but not wsdl
interfaces.
[GlenD: There is a pre-existing "reserveCarRequest" XML data type,
which is to be sent as the body of a WSDL operation.
Unfortunately, the designers of this type did not leave
any extensibility hooks in the schema. The WSDL designer
desires to send two pieces of additional data..... etc]
Roberto: At the interface level operations are imutable, they can't
be changed by extension, whether it is AD or any other
extension.
Sanjiva: Need to make clear in the definition of the AD feature
what can actually be done with it: add data to an existing
schema. At interface level you have to define AD feature
when defining operation. At binding level you can modify
an existing operation.
GlenD: Binding information may be needed for stub generation.
Sanjiva: But that is why wsdl separates interface and binding. Need
to go beyond Xml over SOAP or HTTP. There are other
bindings.
DaveO: Wsdl defines 3 layers, interface, wsdl soap binding,
transport binding.
Umit: Given that AD can't change existing interface what have
we gained over soap:header?
Sanjiva: Can we add text that says that one cannot modify operation
at the interface level?
GlenD: We already have that.
Roberto: Not true, we can add new components as long as we don't
change existing components.
GlenD: Need to fix that.
Roberto: That's the way inheritance works.
GlenD: Shouldn't allow definitions of interfaces with operations
with the same name as an existing one.
New issue: Shouldn't allow redefinition of operation even when they
are the same.
GlenD: Drop the issue.
[dorchard: Umit, I've always thought that this should be the "header"
feature. And then the http and/or soap binding say how
to serialize into their headers. Almost every protocol
spec has a body/header separation and that leaks into the
interface so why not just accept it?]
Resolution to 48d: use Glen's text to clarify AD example.
+ explain in intro to AD feature what the intended use is.
+ SHOULD be used at interface level, discourage use at binding level.
17:30 Adjourn
Received on Tuesday, 16 November 2004 20:43:49 UTC