W3C home > Mailing lists > Public > www-ws-desc@w3.org > November 2004

Minutes, 9 Nov 2004 WS Descripbion WG FTF

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Tue, 16 Nov 2004 12:43:10 -0800
Message-ID: <7DA77BF2392448449D094BCEF67569A505AA1B01@RED-MSG-30.redmond.corp.microsoft.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:33 GMT