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

Minutes: 4 August 2004 WS Description WG FTF

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Tue, 24 Aug 2004 12:17:59 -0700
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA204AAC65F@RED-MSG-30.redmond.corp.microsoft.com>
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 GMT

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