- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Tue, 3 Aug 2004 01:01:34 -0700
- 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
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 ----------------------------------------
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, 3 August 2004 04:01:40 UTC