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

Minutes: 2 August 2004 WS Description WG FTF

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Tue, 3 Aug 2004 01:01:34 -0700
Message-ID: <DF1BAFBC28DF694A823C9A8400E71EA2046D102D@RED-MSG-30.redmond.corp.microsoft.com>
To: <www-ws-desc@w3.org>

Minutes, 2 August 2004 FTF, London
Web Services Description Working Group

09:00 Introductions and logistics
    - Assignment of scribes
      Adi Sakala, Jacek Kopecky, Umit Yalcinalp, Mark Nottingham, 
      Igor Sedukhin, Dale Moberg, David Orchard, Jerry Thrasher,
      Bijan Parsia, Asir Vedamuthu, Glen Daniels, Jeff Mischkinsky,
      Roberto Chinnici, Amy Lewis, Youenn Fablet

Mon: Igor, GlenD
Tue: DaveO, JeffM
Wed: Asir, Jacek

    - Agenda bashing

DaveO:    wants to talk about versioning
DaveO:    a client has no way of knowing when the new interface is
          has a proposal to discuss.
Jonathan: 4 items in the free time bucket
[ Property "required"
  Composition model
  Multiple namespaces and schemas
  Versioning ]
Arthur:   review formalizations in the spec. e.g. remove the ambiguities

09:15 Last Call [2, 3, 4] Stuff
    - Any showstopping issues?
    - Last Call procedures (tracking issues, etc.)
      - Use ExIT?  Jonathan has been using it for XInclude [5]
    - CR preparation
      - Encouraging implementations
      - Start thinking about CR exit criteria.

 [2] http://www.w3.org/2002/ws/desc/wsdl20
 [3] http://www.w3.org/2002/ws/desc/wsdl20-patterns
 [4] http://www.w3.org/2002/ws/desc/wsdl20-bindings
 [5] http://www.w3.org/XML/2004/07/ExIT-xinclude/issues.html

Glen:     need to resolve HTTP application data binding as a reusable
          feature binding or part of the HTTP binding? Section 3.3 in 
          part 2. A feature binding.
DaveO:    Amy&Umit are not here. Noone could argue for "part of HTTP 
          binding" now.
Jonathan: distinguishing between feature and feature-binding
DaveO:    one can look at the binding as the feature too...
Glen:     a B implements a fixed set of features. Any additional is just

          a feature.
Jonathan: this is a feature that binds an abstract feature. So is it 
          a feature binding or just a feature?
DaveO:    this was not part of any proposal yet
Glen:     make a one word change or define the term. the former is 
          simpler to do before LC.  Feature is not restricted to be 
          abstract. It can modify behaviour of anything including 
          concrete bindings.
RESOLUTION: Change "feature-binding" to "feature".
Jonathan: discuss part II. proposed that Glen to be added to part 
          II editors.
RESOLUTION: Glen appointed as part II editor

Jonathan: going through part II edits.  LC logistics. e.g. should we 
          start new issues list...
Glen:     bugzilla?
<asir>    http://www.w3.org/XML/2004/06/scds-pre-lc-issues/
<asir>    in the schema wg
Glen:     potential visions for the way forward and a way to get as much

          as possible done now (i.e. before October?)  Talk about 
          various possible outcomes when certain specs become
Jonathan: how do we get through the issues... assign champions... 200 
          issues to go though before CR.  Better to have short LC.
          Are we ok with 60 days...
Hugo:     what is the last date for LC (now Oct 4th).
Jonathan: get comment, acknowledge, WG response
Jacek:    this may be too complicated for small editorial comments
Jonathan: may help to separate: discussion -> positions and discussions
          around actual spec modifications.  Get a wider internal review

          of LC.  After LC -> CR... develop test suites...
Jonathan: is there an AB rec how the test materials are handled...
...noone remembers...
ACTION:   Jonathan to followup on AB decisions with regards to test 
          materials handling...
Arthur:   1) WSDL->code 2) test messages
Jonathan: for CR we may want to consider distingushing the applications 
          that comply with WSDL
DaveO:    why don't we just run it via WS-I :)
Glen:     this is the exit criteria for W3C
Paul:     how high is the bar for CR?
<jeffm>   ws-i's IPR rules prohibit this WG doing anything formal with 
          WS-I wrt testing - sigh :-(
Paul:     contribute test cases
Jonathan: there are usually 2-3 big contributors instead of many
Arthur:   there is no point to rush to CR. Value of the spec will be 
          greater if we can show that there are actually a number of 
          interoperable impls.
Arthur:   implementations first instead of publish a spec and then 
          find issues
Jonathan: there could be some bug fixing period for implementers that 
          may affect the CR then
Glen:     Axis -- months to get to the impl
Paul:     migration is a good test case.
Jonathan: does not guarantee that all WSDL 2.0 features are tested that
Paul:     it may be a subset, but it is very useful e.g. for BT
Arthur:   are there W3C guidelines on exit criteria
Jonathan: there should be 2 interoperable impls, but even that is vague.

          1) implementable 2) interoperable
<pauld>   http://www.w3.org/QA/
Anish:    isn't there a QA working group...
Jonathan: QA may point to examples, but they don't actually implement 
          WSDL-specific things
Jonathan: QA verifies a check list for specs
<pauld>   QA Test
Hugo:     at CR have an interop F2F
Jonathan: January?...
WG:       there won't be much done by then
Hugo:     our schedule Jan/March proposed REC...
DaveO:    what are the potential "bars"...
Jonathan: we can say there must be 5 interoperable impls or something
Jonathan: example. for some obscure feature we can require at least 1
          implementation, but e.g. 2 interoperable impls of the whole 
DaveO:    MUST bar is 1, SHOULD is 2 and MAY = many
DaveO:    is there an interest to set a bar > 2 on anything...
Glen:     volunteers to sest x against y instead of managed process
<anish>   SOAP 1.2 implementation summary and interop coverage --
Bijan:    what are the test assertions. what the def of "interoperable"
Bijan:    there could be assertions that are just not practical to
JeffM:    individual tests are not sufficient for general interop.
DaveO:    forest of features vs. tree
JeffM:    yes
JeffM:    WS-I does interop among the spec forest
DaveO:    impl of all of the WSDL features interops with another impl of

          the same features. 
DaveO:    quality vs time tradeoff
DaveO:    75% implemented, but then how does one pick that 75%...
Bijan:    are there serious ambiguities in the spec that this becomes 
          the problem?
Jonathan: noone knows
Bijan:    analytically... we've all read the spec
Arthur:   we have a historical track record of such ambiguities (WSDL
          spec is subject of the interpretation.
Arthur:   initial period of impls. is QA on our spec. that is why it 
          is needed. we need enough confidence ouselves that we can 
          implement this.
JeffM:    say 2.0 is better crafted... there will be ambiguities... 
          something has to happen, but does not say how -> up to 
JeffM:    yes it is a Q of time. the reality is how the specs are 
          regarded in the market space by users.
Paul:     this process is to improve Q of the spec. implementations may 
          help to resolve ambiguities. formal impl may not help..
Paul:     if 2.0 is that far people may not want to move from 1.1..
Bijan:    there are certain places in the spec e.g. F/P where
          there are ambiguities.
Bijan:    there is no help in delayng until reference impls (?)
<pauld>   wonders if at some level if the testpack could be seen as a 
          reference implementation
Jonathan: put out the spec + test cases. we can't make anyone impl the 
          spec or be interoperable. we can only serve and not dictate
Jacek:    impls choose those features that are important for that impl.
          should not manadatorily test against all
DaveO:    danger: CR period = standards body certification. We shouldn't
DaveO:    our CR citeria should be: 2 interop impls of a feature
Bijan:    what is impl: is it a validator or actual use case?
DaveO:    whatever we mean by 2 of them :)..
Arthur:   pairwise testing is good enough
[Arthur is making a point...]
Glen:     graph of feature dependencies exists by just following the
          rely on this process rather than 2wise tests.
Paul:     ir is not a number of impls, it is the test cases themselves
Jacek:    with 2wise tests one already implements the other needed 
          features anyways cuz' otherwise it won't work
JeffM:    conclusions from WS-I says 2 is not enough
Anish:    a feature could be an aggregate, so it is not testing in 
          isilation. this worked for SOAP
Roberto:  agreeds with JeffM. it becomes "works by accident" otherwise.
Roberto:  testing processors for understanding of the doc model.. if we 
          stay at the component model it'll be much easier than testing 
          on the wire
DaveO:    2wise tests of a feature is a good thing. SOAP 1.2 is a
[2wise with a predecessor...?]
Jonathan: how can we serve the interop. we don't do interop actually. 
          we just help it be better...
Bijan:    1) formal criteria for CR and 2) group criteria for voting to 
          move to CR

10:30 Break     ----------------------------------------

10:50 Media Type Description Note [6]
    - Outstanding issues [7]
    - Issue 161: Should media-type values allow wild cards [8]

 [8] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0293.html

Jonathan: any objection to closing issue 161 as already implemented?
[discussion between Anish/Hugo: */* solves it by saying anything goes.
schema validation provides more information...]
Jonathan: is this a real issue of is it just because spec is written 
          in the weird way?
Hugo:     may be remove the sentence and close the issue
Anish:    would be happy if that was done.
Jonathan: close 161 because we already allow *. Remove the sentence that
          causing confusion.
Jonathan: any objections.

    - Issue 245: Define expectedMediaTypeItem to be RFC 2616 Accepts

Hugo:     [introduced the issue]
Anish:    this was meant for WSDL processors to describe what is
expected so
          that it can be received. what is the motivation for the "q"
Hugo:     this is just to specify preferences
Anish:    there are no other places where we specify preferences. Why 
          is this so special?
Hugo:     we already have a mechanism and we can just allow to specify 
          preferences e.g quality
Helen:    medical use case: whatever image format you must just accept 
          It. That is the regulation.  "q" parameter does not help this 
          use case
Hugo:     decide useful or not, then see what to put in the spec
Jonathan: useful or not? opinions...
Bijan:    there are various mechanisms how the policies are negotiated
Anish:    wants to keep the schema simple
Jonathan: strawpoll: should a Quality parameter to be added to the 
Results:  5 for it 1 against 11 abstained
Jonathan: going back to the spec proposals
Jonathan: is there a synergy to allow any paremeters or is Q a specific 
          one that needs to be added
Anish:    parameters + acceptParameters 
Jonathan: looses the ability to validate, what are the pros of allowing 
          any parameters
Jonathan: potential threat to interop
Jacek:    just do the Q, space separated may be
Jonathan: keep the Q and not allow arbitrary parameters.
<pauld>   RFC2616: http://www.faqs.org/rfcs/rfc2616.html
<pauld>   Section 14
Jonathan: should we just adopt the parameter: Q, nothing else, point 
          to rfc2616
Jonathan: don't have to express that in a pattern
Jonathan: the above is the proposal (Hugo's)
Jonathan: won't do ",", only do Q and go back to */*
Helen:    "," is the problem with i18n
Jonathan: 2616 already says what the grammar should be.
DBooth:   2616 says it is "." 
Anish:    " are allowed or not?
Jonathan: objections to adopting the proposal?
[... no ...]

12:30 Lunch     ----------------------------------------

13:30 Media Type Description Note (cont.)

    - Issue 204: Why default to */* instead of to "no effect"? 

[asir: http://www.w3.org/2002/ws/desc/2/06/issues.html#x204]
Jacek:    didn't we remove this?
[various: yes, but now we have */*]
Jacek:    */* means everything goes
Anish:    doesn't say anything about opaque or app/octet-stream 
          now, everything is allowed
Jonathan: this is obsolete - can we close it?
[no disagreement]
RESOLUTION: Issue 204 closed as obsoleted by Issue 161

    - Issue 162: Allowing other choices for mediaType values [9]

[9] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0294.html

Issue 162
Jonathan: close it?
[no disagreement]
RESOLUTION: Issue 162 closed; obsolete issue

    - Issue 198: mismatch between value of media type attribute and

[Issue is doesn't say anything about what happens when the value of 
content-type attribute differs from the media type specified]
Jonathan: should this be treated like a mismatched schema?
Glen:     does WSDL say anything about that?
Anish:    treat it the same way we do schema, if it's silent fine
Jonathan: runtime problems are perhaps out of scope? objection to
RESOLUTION: Issue 198 closed with no action

    - Issue 199: mismatch between the media type attribute and the

What if the contents are wrong/bad?
Jonathan: this is also out of scope (see 198)
Anish:    Yup, proposal on list which says that.
[objection to closing?]
Anish:    do we point out that we're not dealing with this, or stay 
          silent about it?
Asir:     silent
RESOLUTION: Issue 199 closed with no action

    - Issue 200: Where should appInfo go? 

Jonathan detours, to talk about attributes vs. annotations
Jonathan: can we use attribute for e-m-t as well?
Asir and Glen generally like this idea
Jonathan: expose as attribute and react based on feedback
Anish:    some of the tools do not expose out-of-band attribute
Anish:    better interop via appInfo element
Arthur:   how big is this info?
Anish:    open a new issue
Marsh:    describes the issue
Anish:    argues for attaching expectedMedia type info to type or
Glen:     out-of-band attribute or appInfo element, should be allowed 
          on type or element
Marsh:    can we attach this to a model group?  or any other schema
Roberto:  nope, I don't think so
Jonathan: proposal is to add a sentence/para saying where this 
          annotation may appear
any objections?
RESOLUTION: Issue 200 closed; annotation may appear on elements and

(discussion of attribute vs. appInfo)
Arthur looks at Xerces API
[asir: see
Xerces API is horrible, apparently. Only offers a single "annotation
string" which we don't know what it is
Glen:     we don't use Xerces API for parsing schema, we do it ourselves
Roberto:  us too
Arthur:   We use it.
Glen:     do you then look into that to resolve things?
Arthur:   yes, types and element declarations
(discussion of APIs, which led to the conclusion that if you have to
parse the DOM anyway, it's no harder to get appInfo than it is to get
[asir: .NET XMLSchemaAnnotation class is at
DaveO:    We have pseudo-schema this time around, so can't just validate

          WSDL with schema
Arthur:   Right, the rest is code
Paul:     Doesn't schema have a component model?
Glen:     Yes, but Xerces apparently doesn't do all of it.
Asir:     Many impls probably don't 
Glen:     All toolkits I know of do the schema parsing themselves... 
[asir: Anish, it is at
Arthur:   Eclipse model looks better
Roberto:  Yeah, this is needed for JAXB too
straw poll - attribute vs. appInfo
Results: 9 for attribute, 1 for element, 4 abstains
Jonathan: In any case, we should probably flag this as an ed note
Anish:    can we postpone until tomorrow?
Jonathan: sure.
WG is therefore substantially in favor of moving to attribute syntax if
NEW ISSUE 252 - syntax of media type annotation
Will resolve for LC tomorrow pending a little research by Anish tonight.

    - Issue 201: Name of mediaType [10]

[10] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0295.html

RESOLUTION: Issue 201 closed; already resolved

    - Issue 202: More examples 

Jonathan: Yea verily.
Arthur:   Test suite might help here
Jonathan: what do we need in the text?
Anish:    Examples with new stuff (*/*, etc)
Anish:    issue raiser wanted an example with static type (fixed at 
          schema definition time)
ACTION:   Anish to write up some examples and add them to the spec
Arthur:   Let's make sure that we have this as a test case as well
          (discussion of how to keep content in sync)
RESOLUTION: 202 CLOSED with Anish's todo
For now we'll manually make sure examples in the spec are copied to the
test suite, as opposed to scripting such a thing.

    - Issue 203: Limited to base64encoded? 

Why is this limited to base64encoded?
Anish:    Is this asking for the rationale, or asking for other types?
Jonathan: other types, probably
[(discussion of which types should be allowable)
Question comes down to - can media type designator be factored out from
MTOM such that it can be used in different situtations, and then MTOM
can restrict it]
Jacek:    We're attaching content-type info to the value of an element 
          (not the lexical rep thereof). Can't assign media types to, 
          for instance, numbers...so doesn't make sense for xsd:int.... 
          just octet-streams
[general agreement we should expand to allow hexBinary]
(discussion of strings and character sets and embedding docs within
docs, which gets back to desire to restrict to binary)
Jonathan: worth adding rationale text in doc?
Anish:    put it in the closing email, but not in the doc...
[JacekK: rationale for contentType on hexBinary (and base64binary): 
         content types can be applied to sequences of octets, therefore 
         the XML Schema types whose value sets are sequences of octets 
         can be annotated with content type]
Jonathan: Objections to closing 203 by adding hexBinary to allowable 
          media types?
no objections
RESOULTION: Issue 203 closed by adding hexBinary.

    - Issue 205: Explain priority [11]

[11] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0296.html

Explain priority
Jonathan:  This might be fixed already
RESOLUTION: Issue 205 closed; obsolete

    - Issue 206: Annotations and schema component model. [12]

[12] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0297.html

RESOLUTION: Issue 206 closed; obsolete, and duplicates 200

    - Issue 242: Binding accepts header and output serialization  

> - expectedMediaType placed on an input message is equivalent to an
> Accept header from the POV of the service.
(discussion of whether or not we need to change any text)
Glen suggests perhaps putting this info into the primer, and not the
spec itself, since it's informative but not normative
(lots of buck-passing about where this should go)
Hugo:     now that we support quality param, it's more and more obvious 
          that there is a parallel... maybe we just add a sentence in 
          the media-type doc drawing the analogy/parallel.
Anish:    this already exists in the media-types doc....
proposal: s/"the value of the "/"the value, and the meaning thereof, of 
          the "/ in the media type doc
[hugo: +1]
"the value and the meaning of the "
this is section 2.2, third paragraph, of the media type doc
ACTION: Editors to make a change to section of 2.2 of the media type doc
to reflect that the meaning (not just the value space) of the expected
media type is the same as the accept header.
RESOLUTION: Issue 242 closed by making a change to section 2.2 of the
            type doc to reflect that the meaning (not just the value
            of the expectedMediaType is the same as the Accept header.

15:30 Break     ----------------------------------------

Jonathan: let's check AIs; NOW = Roberto doing as we speak.
DONE     2004-05-21: Editors to add ednotes to the spec to indicate 
                     areas that had contention. (Issue 190)
NOW      2004-06-17: Editors to incorporate David Booth's clarification 
                     in section 8.3
DONE     2004-07-08: Editors to implement resolution to 177 as amended.

(discussion of 177 and whether we should rejigger the types in the SOAP
1.2 binding)
177 editorial work was done, but after reviewing that work we have a new
issue, which Asir will mail to the list.

DONE     2004-07-08: Glen to verifiy composition model.
DONE     2004-07-15: People who want to file a minority opinion should 
                     do so by July 22.
DONE     2004-07-15: Editors to incorporate Operation Name proposal v3
DONE     2004-07-29: Editors implement proposal (Issue 250).
DONE     2004-07-29: Editors incorporate Glen's "some new text" into 
                     section 2.8.1 of part 1.
NOW      2004-07-29: Editors incorporate text from thread "please review

                     text" (333) with changes of provider agent to 
NOW      2004-07-29: Editors remove entire text of Issue 211 resolution.
DONE     2004-07-29: Editors to move "AD Feature/HTTP binding" material 
                     into part 2.
DONE     2004-07-29: Editors add comment about how the wrapper element 
                     is defined.

15:50 XMLP Last Call comment disposition
    - XMLP WG response to our comments [13, 14, 15]

[13] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0036.html
[14] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0006.html
[15] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0272.html

XMLP Last Call comment disposition
[Marsh: http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x489]
Jonathan: Are we ok with this?
Glen:     No. It would be good to understand why they made that
          If it's a good reason, then fine, but we'd like to know a 
          little more than "no action".
ACTION:   Glen to inquire to XMLP about the rationale for closing 489
[anish:   http://www.w3.org/2000/xp/Group/4/06/30-minutes.html]
[anish:   url to the minutes of XMLP concall above (search for issue
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0272.html is
done, and we're fine with it
[asir:    XMLP issue 490]
Jonathan got private response about issue 490, which says they accept it
with a tweak
[Summary: 3 issue resolutions accepted, one not (490)]

16:30 Intermediaries [16, 17]

[16] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0366.html
[17] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0369.html

Hugo:    notes that "intermediary" does not even exist as a term
         in the current SOAP binding
[asir:   I don't believe that AD feature allows actor attribute, Hugo?]
In a way we sort of support intermediaries by using the AD feature with
SOAP role/actor attributes in the schema... but should we do something
like <soap:module role="..."/>
Glen:    no
Roberto: No
Glen:    Modules can do lots of different things, and might for 
         instance have the role attributes fixed in the spec. Therefore 
         it seems tricky to suggest that ALL modules should support
         Plus module authors can specify properties for this....
DaveO:   It's really hard to describe all the potential transformations 
         as a message moves from a sender to an ultimate destination...
DaveO:   We are not yet ready to move into this problem space. If we try

         to do it now, we're never going to ship.
[hugo:   asir, hmmm... I thought it did, but you're right, I don't see 
         it anymore...]
[hugo:   asir, actually, I don't think that there are limits to what you

         can use, including the actor attribute]
(discussion about using a property for this kind of thing, and the fact
that this pretty much enables this kind of thing *for specs which
explicitly write this functionality in*, which seems good)
Proposal: do nothing for now
(discussion of dropping the requirement)
Proposal from DaveB
Drop the requirement because:
1) Although WSDL does not provide explicit support for intermediaries,
it is possible using existing extension mechanisms to indicate that
intermediaries are in use and configurable
2) We do not have a clear understanding of what would be needed in order
to more fully support intermediaries
3) Insufficient support in the WG to pursue this further
Proposal is to amend the requirements doc by deprecating/greying-out the
requirement and adding the above text.
RESOLUTION: Deprecate Intermediaries requirement
ACTION: Marsh to update Req doc to deprecate intermediaries requirement

17:00 Adjourn
Received on Tuesday, 3 August 2004 04:01:40 GMT

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