[Corrected] Minutes: 2 August 2004 WS Description WG FTF

Minutes, 2 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
 Adrian Smith           British Telecom

Regrets:
 Ugo Corda              SeeBeyond 
 Martin Gudgin          Microsoft 
 Peter Madziak          Agfa-Gevaert N. V.
 Jean-Jacques Moreau    Canon 
 Jeffrey Schlimmer      Microsoft
 Prasad Yendluri        webMethods, Inc.



-------------------------------------------------------
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

Scribe: Igor

-------------------------------------------------------
    - Agenda bashing

DaveO:    wants to talk about versioning
DaveO:    a client has no way of knowing when the new interface is
deployed. 
          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.
<Roberto>
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0397.html
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
available...
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
way
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
Guidelines:http://www.w3.org/TR/2004/WD-qaframe-test-20040225/
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
lower
Jonathan: example. for some obscure feature we can require at least 1
          implementation, but e.g. 2 interoperable impls of the whole 
          spec
DaveO:    MUST bar is 1, SHOULD is 2 and MAY = many
DaveO:    is there an interest to set a bar > 2 on anything...
...no...
Glen:     volunteers to sest x against y instead of managed process
<anish>   SOAP 1.2 implementation summary and interop coverage --
http://www.w3.org/2000/xp/Group/2/03/soap1.2implementation.html
Bijan:    what are the test assertions. what the def of "interoperable"
Bijan:    there could be assertions that are just not practical to
implement
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
1.1).
          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 
          interpretation
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
analytically 
          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.
we 
          should not manadatorily test against all
DaveO:    danger: CR period = standards body certification. We shouldn't
get 
          there.
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
spec.
          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
reference
[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]

 [6]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/media-types/xml-media-t
ypes.html?content-type=text/html;%20charset=utf-8
 [7]
http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/issues/wsd-issues.h
tml
 [8] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0293.html

<anish>
http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/issues/wsd-issues.h
tml#x161
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
is
          causing confusion.
Jonathan: any objections.
[...no...]
RESOLUTION: ISSUE 161: CLOSED

-------------------------------------------------------
    - Issue 245: Define expectedMediaTypeItem to be RFC 2616 Accepts
header

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"
          parameter?
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 
          expectedMediaType
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 ...]
RESULTION: ISSUE 245: CLOSED

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

Scribe: Glen

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
                 pattern 

[http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/issues/wsd-issues.
html#x198]
[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
closing?
RESOLUTION: Issue 198 closed with no action

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

[http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/issues/wsd-issues.
html#x199]
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? 

[http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/issues/wsd-issues.
html#x200]
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
element
[anish:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Aug/0005.html]
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
          component?
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
types.

(discussion of attribute vs. appInfo)
Arthur looks at Xerces API
[asir: see
http://www.w3.org/Submission/2004/SUBM-xmlschema-api-20040309/xml-schema
-api.html#Interface-XSAnnotation]
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
attributes)
[asir: .NET XMLSchemaAnnotation class is at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/h
tml/frlrfsystemxmlschemaxmlschemaannotationclasstopic.asp]
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
http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#cAnnotations]
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
possible.
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

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
media
            type doc to reflect that the meaning (not just the value
space)
            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 
                     service.
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
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0036.html
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0006.html
[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
decision. 
          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
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0272.html
[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
489)]
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

Intermediaries
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0366.html
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0369.html
Hugo:    notes that "intermediary" does not even exist as a term
anywhere 
         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
this... 
         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, 24 August 2004 19:11:43 UTC