- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Fri, 17 Sep 2004 17:43:07 -0700
- To: <www-ws-desc@w3.org>
Web Services Description F2F
Wednesday 15 Sep 2004
See also: IRC log [http://www.w3.org/2004/09/15-ws-desc-irc]
Attendees:
David Booth W3C
Helen Chen Agfa-Gevaert N. V.
Roberto Chinnici Sun Microsystems
Glen Daniels Sonic Software
Paul Downey British Telecommunications
Hao He Thomsona
Tom Jordahl Macromedia
Anish Karmarkar Oracle
Kevin Canyang Liu SAP
Jonathan Marsh Chair (Microsoft)
David Orchard BEA Systems
Bijan Parsia University of Maryland MIND Lab
Arthur Ryman IBM
Sanjiva Weerawarana IBM
Phone:
Allen Brookes Rogue Wave Software
Youenn Fablet Canon
Jean-Jacques Moreau Canon
Regrets:
Hugo Haas W3C
Amelia Lewis TIBCO
Asir Vedamuthu webMethods
Scribe: Kevin Liu
-------------------------------------------------------
Wednesday 15 September
-------------------------------------------------------
09:00 Last Call Issues
Jonathan: Arthur has a call till 10am. agenda this morning changed.
Continue last call issues.
-------------------------------------------------------
Issue LC8: "Permit URI References instead of URIs "
Roberto, Jim: text sounds like encoded
[Roberto: http://www.w3.org/TR/xmlschema-2/#anyURI]
Roberto referred to schema spec for uri reference
DBooth: What do we need to do?
Roberto: Use URI reference, use the same trick as schema.
[Group looks at schema spec part 2 section 3.2.17 for anyURI]
Bijan: Using qname is more consistent with rest of the spec?
Glen: We had discussion in Palo Alto, was for it, but it
was shut down.
Roberto: Find out where we are using anyURI type.
Jonathan: And figure out whether we should allow URI reference
[more discussion on using frag id]
[dbooth:
http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#fragment]
[dbooth: "As such, the fragment identifier is not used in the
scheme-specific processing of a URI; instead, the fragment
identifier is separated from the rest of the URI prior to a
dereference, and thus the identifying information within
the fragment itself is dereferenced solely by the user agent
and regardless of the URI scheme."]
DBooth, Roberto, Jonathan: what to do in the spec?
[Frag id is stricken out before deferencing. It's up to applications
decide
how to deal with it. It's web arch issue, nothing specific to web
services.
Seems schema spec doesn't really say anything about anyURI's value
space.]
Jonathan: Gave three example URI's in white board (using e-acute vs.
%-escaped value), all same except some contain spaces. Are
they all the same value space? They are in different
namespaces,
so ns processor treat them differently.
[hugo: http://www.w3.org/TR/2004/WD-wsdl20-20040803/#uricompare]
JM checking section 2.19 of part 1 for our definition of "comparing
uris"
Jonathan: If we add a frag id to the end of any of the uri, it's
different.
Don't see problem allowing frag in URI. We are OK with frag
id.
[Our def of uri need a little update to make it clear its actually uri
reference.]
Sanjiva: Why not define our own type?
Jonathan: We should keep our type as close to schema as we can.
ACTION: Editors update spec to clarify our using of anyURI is actually
URI reference except targetNS
RESOLUTION: LC8 closed by allowing # everywhere but targetNamespace.
-------------------------------------------------------
Issue LC9: How does the Operation Name Mapping Requirement (Part 1,
section 2.2.1.1) relate to interface inheritance?
Glen: It's is not only for operation name, a general composition
issue.
Spec is not clear. We should add a paragraph to clarify this.
DBooth: We already have a section for that.
Glen: We need to answer Tim.
[The answer to his first question is yes, but what to do with spec is
not yet clear.]
DBooth: Conformance section says something. (section 6.1)
ACTION: Glen to respond to Tim saying yes to his first question,
and pointing out sections 6.
Jonathan: Answers to Tim's three questions: yes, n/a, no
[dbooth: Operation name mapping requirement:
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?cont
ent-type=text/html;%20charset=utf-8#Interface_OperationName]
[Disscusion on what to do with spec/]
Glen: Section2.2.1.1 should be clarified. When you are using a
service,
it's got an interface, plus we should write it in English :)
ACTION: Editors to clarify spec about operation name mapping
requirements
by moving paragraph preceeding section 2.2.1.1 and whole
2.2.1.1
to service section, and clear up the text.
[Marsh: RESOLUTION: LC9 closed]
[dbooth: The intent of this action is to associate the operation name
mapping requirement with a *service* rather than an interface,
so that the requirement only applies when an interface is
actually
used by a service.]
[GlenD: Clarification on this action - "clear up the text" means
1) make clear that this applies to the interface component of
the service component, and 2) indicate that any in-scope
feature
or extension (scoping of extensions left as an exercise to the
author) may satisfy the ONR]
[dbooth: This also means that the prose in list item 1 of "2.2.1.1
Operation Name Mapping Requirement" should NOT refer only to
properties of the interface component, due to the F&P
inheritance rules defined in e.g. "2.7.1.1 Feature Composition
Model".]
11:00 Break ----------------------------------------
-------------------------------------------------------
11:30 Zed notation update/QA issues
Arthur is ready to present Zed notation
Authur: will send material to www archival mail list . Basically we
have
an xml source, it can be translated naturally into math and
generate test assertions.
[dbooth: Arthur draws on the board:
|
| XSLT
| XML ------------> HTML + CSS
| \
| \ XSLT fuzz
| \----------> Tex ---------> TypeErrors
| \
| \ Tex
| \-------> PDF
]
Hugo, Roberto are concerned about browser sniffing
Arthur: Shows chart for "rendering Z notation symbols in a web page"
and
demos how IE and Mozilla behave differently.
[pauld: arthur's question to the mathml WG:
http://lists.w3.org/Archives/Public/www-math/2004Sep/0009.html]
Arthur: Demos how fuzz does type check and generates type errors
and think fuzz type checking is quick and useful. Addreses
hugo's concern on browser dependency for rendering the zed
html. It will be problem for this generation is to be
published
in W3C if browser dependency issue can not be solved.
[Now group discusses how this affect our spec assuming rendering problem
can be fixed.]
Arthur: Shows a generated normal version of wsdl2.0 spec and how
interface
component looks like. It has mathematical expression and
English
explanations.
[alewis: url?]
Sanjiva: Is concerned changing the spec after the last call.
[it's ok to add to what's already published.]
DBooth: This is not change to the semantic of the spec.
Anish, Roberto: Aare concerned another additional presentation will add
more confusion.
[We already have component model, infoset model, now add zed notation?]
dbooth: There are a few ways to go:
1. replace the current notation,
2. in addition to current notation...
Paul: Find zed is easier to read than informal notation
Sanjiva: Would like to see how the spec looks like with this new
notation
before we decide anything.
[Now discuss possible impact on our publication schedule, may need
another last call.]
ACTION: Arthur to (re)write a subsection of the spec to show exactly
how
it looks with the Zed notation included before next telecon.
ACTION: Hugo to investigate potential options for get the Zed version
published in W3C web site.
Tomj: Is concerned adding the z will make the spec more intimidating
to read.
Arthur: Will do this for QA anyway. Doesn't hurt to give it a try with
the spec, we will see how people feel about it
[Arthur: fyi, I posted the pdf of the XML Infoset Spec to
http://lists.w3.org/Archives/Public/www-archive/2004Sep/0027.html]
[Arthur: The Z notation for it, that is]
[Arthur: Watch the www-archive - I posted it too but it hasn't shown
up
in the list yet.]
-------------------------------------------------------
12:45 Last Call issues [8]
- (In issues list order, with Asir's last if possible)
[8] http://www.w3.org/2002/ws/desc/4/lc-issues/
-------------------------------------------------------
Issue LC29a: It's unclear why default binding rules are not defined for
fault components.
Roberto: Useful info in binding fault is the code and subcode, there is
no good value to provide as the default code and subcode.
RESOLUTION: Add a rationale to the spec explaining there is no good
default value for code and subcode.
ACTION: Editors to add rationale to spec to explain why no default for
binding fault is defined (no good default codes)
Tomj: Suggests involving a tech writer to inspect the spec and fix
similar issues.
Hugo: You need to spend a lot of time to talk to a tech writer to
get the job done.
dbooth: Not sure the result will be significantly better.
13:00 Lunch ----------------------------------------
[dbooth: Scribe: Sanjiva]
-------------------------------------------------------
14:00 Individually read the Media Types Spec
[tomj: http://tinyurl.com/6mvur]
[sanjiva: we're spsed to be reading the media types spec now ..]
[Marsh:
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/media-types/xml-media-t
ypes.html?rev=1.11]
[dbooth: My talk on What's New in WSDL 2.0:
http://www.w3.org/2004/Talks/0915-dbooth-wsdl/]
14:15 Additional media type comments
Discussion about rationale for why the expectedMediaTypes attribute has
restricted MIME parameters to the 'q' parameter.
Sanjiva: Make it be consistent with what HTTP has unless we have good
reason not to.
Jonathan: Is this totally congruent to accept header, which would
rationalize following HTTP rules?
Tom: Doesn't think so
[hugo: Minutes from last discussion:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Aug/0054.html]
[tomj: q is the only argument to the Accept header in section 14.1.
The other arguments are extensibility, and we don't want or
need the extensibility point here.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1
So we are not limiting a list of things to just q, we are
supporting all the specified options, but none of the
"accept-extension" options.]
Straw poll on whether to follow Accept: or whether to restrict the value
to be only with the q parameter without the extension capability.
Yes change to follow the http spec: 4
No leave it alone: 4
[Allen: abstain]
[youenn: abstain also]
take the vote again because of some flip-flopping...
Yes: 6
No (status quo): 4
Objections to moving forward? Tom can't live with it.
[pauld: Voted in order to loose the schema pattern ]
Tom: Change the status quo to say "we allow the parameters defined
by http ('q') but we don't allow the extensibility".
Discussion about why we change the actual syntax from what's in HTTP.
Sanjiva: Proposes to change the syntax to follow the http spec, drop
the pattern facet from the schema, and say that the format of
the string which follows the appropriate production in the
HTTP RFC (except for not supporting extensions)
Jonathan: Any objections to the above?
Nope, we're all happy campers.
ACTION: Media type editors to change the syntax to follow the http
spec,
drop the pattern facet from the schema, and say that the
format
of the string which follows the appropriate production in the
HTTP RFC (except for not supporting extensions).
Tom: The media type document doesn't seem to explain how this
actually fits together ..
DaveO: Write a primer for the media types spec?
Tom: What about an overview section? Words like "here's the
problem we're trying to solve, you put this stuff in the
schema, then at runtime this happens and this is how it
works"
Consensus to add some more text in the introduction.
ACTION: Tom and Anish to figure out the right words.
Jonathan: Status section of the doc has "Second Public Working Draft"
incorrect capitalization and too many words in the link.
The status section is going to change anyway .. so above comment will
get fixed automatically.
Jonathan: 2nd bullet of requirements has redundancy in the last
sentence:
combine with previous occurrence.
ACTION: Media Type editor to remove last sentence of 2nd bullet, combine
with previous occurrence (remove redundancy).
Jonathan: Section (2) refers to requirements by number when the reqs
are
an ULIST. Oops.
ACTION: Media Type editor to make requirements an OLIST.
Jonathan: Section 3 defines a binary EII as defining additional infoset
props: These are not additional infoset props.. they are more
constraints on current ones.
Glen: Offers wording: "A binary EII is an EII defined as follows
...."
ACTION: Media Type editor to clarify binary EII term, a la "a binary EII
is
an EII defined as follows"
(More discussion about the document wording .. low level editorial type
stuff.)
Consensus to change examples to have one example which uses the full
syntax instead of the authoring convenience types.
ACTION: Media Type editor to have at least one example which uses the
full
syntax instead of the convenience types.
Jonathan: remove ":" from 2nd para of 3.1 after "both"
Straw poll on whether to remove colon?
Nahh, we will remove it ...
ACTION: Media Type editor to remove colon from 2nd para of 3.1.
Anish: Would like to add an example of a schema and an instance doc
Sanjiva: Appendix for schema definition: use "xmlmime" as the namespace
prefix instead of "tns".
Jonathan formally appoints Anish as editor of the spec from the wsdl wg
too. He is already the editor from the xmlp group.
He accepts it with a lot of worry about the additional work thereby
created.
Jonathan: Next steps: update the document, declare as WSDL LC and ask
our
dual personality editor to take it to XMLP to agree to LC
status.
If they agree the doc goes to LC and thence to a Note.
-------------------------------------------------------
15:00 Last Call issues (cont.)
Issue LC29b
Skipped till glen is back.
Issue 29c
Hugo: There is not resonable default for HTTP binding?
Jonathan: Do exactly what we did for the previous issue (LC29a)?
[hugo: It could be 400 or 500 depending on whether it is a client
or service error.]
ACTION: Editors to record same solution for Issue 29C as the
resolution
for why faults are not given a default binding
discussion (again) whether that was the right decision ...
Roberto: Suggests that we could just always use 500 as the status code
because app level faults (those that are described in WSDL)
fault because of app problems on the server: meaning 500
RESOLUTION: We will resolve this issue as before (no default for WSDL
faults).
ACTION: Editors to implement a fix for LC29c similar to the fix for
LC29a.
Roberto has raised a LC issue against us whether to allow setting the
"reason phrase" for HTTP 500/400 etc. responses.
-------------------------------------------------------
Issue 29b:
Glen says Mark got it wrong - Glen will send an email explaining to Mark
...
ACTION: Glen to send email to Mark
ACTION: Glen to write an ACTION item to implement this ACTION item.
[Marsh: RESOLUTION: LC29b closed, no action.]
-------------------------------------------------------
Issue 29d
Skip until DaveO returns
-------------------------------------------------------
Issue 29e:
The spec already says what happens if element is not there. We will
clarify that nil-valued elems will result in the empty string.
Discussion about how our current binding rules (which says that if the
element is missing then its a fault) doesn't support the case of
elements defined with minOccurs=0
[pauld: An area we see lots of implementations issues is with
combinations of minOccurs=0 and nillable=true]
Jonathan: For the case of URI construction, it seems to make sense to
say nil values (instance data that has xsi:nil=true on it)
result in the empty string being created
[pauld: Schema spec has been open to interpretation here:
http://www.w3.org/TR/xmlschema-1/#cElement_Declarations]
Lots of discussion about whether we are being schema-correct
Straw poll
option1: nils are treated as empty strings for purpose of URI
construction (including param replacemetn)
option2: outlaw nillable elements and hang them if they appear in
schemas that are going to be used in http bindings
no vote taken .. more discussion happenin'
Proposed compromise: instead of disallowing nillable types, we say that
its an error for instance documents to have elements with xsi:nil=true
[Roberto: in the first bullet point of 3.8.1.1]
Any objection for this compromise?
nope; accepted
RESOLUTION: It is an error for instance documents to have elements with
xsi:nil=true.
ACTION: Editors to add as 1st bullet of 3.8.1.1 that it is an error for
instance documents to have elements with xsi:nil=true.
Tom: Proposes the same solution for 3.8.1.2
Roberto: Suggests that for automatically dropped parameters its better
to silently omit it ..
Tom convinced Roberto that its better to be an error because there's a
diff between missing values and minoccurs=0 cases
[Roberto: promptly changed his mind since there is loss of information
in this case]
Consensus to make it an error to have nillable values when trying to
auto generate parameters
[Roberto: "uncited non-nil, non-list, possibly empty single values"]
[tomj: Also change bullet items to be "Uncited elements with single
values (including empty values, but not nil)..."]
RESOULTION: It is an error to have nil values when trying to
auto-generate
parameters.
ACTION: Editors to change first bullet of section 3.8.1.1. to say
"Uncited non-nil elements with a possibly empty single value
are serialized ..."
Close 29e with the above changes.
-------------------------------------------------------
Issue 29f
Same resolution as before - nil values cause errors
RESOLUTION: close 29f with the same resolution as 29e (add bullet to
3.8.3)
ACTION: Jonathan to ask XForms folks to review WSDL.
-------------------------------------------------------
Issue 29g
comment 1: deal with forward reference from 3.8 (ser formats) to 3.9
(styles). Classified as editorial.
comment 2 of 29g: we don't see a need to have a default style
ACTION: Jonathan to split 29g to two issues: first one to be tagged
editorial, 2nd (29h) to be closed as no need to do it.
RESOLUTION: 29h closed - no need.
-------------------------------------------------------
Book-keeping of issues list
Proposal: mark 32, 34a, 35, 36, 39 and 40 as editorial and refer to
editors.
ACTION: Editors to implement editorial issues 29g, 32, 34a, 35, 36,
39 and 40 or come back to the WG with questions.
[tomj: done for the day!]
17:00 Adjourn
Received on Saturday, 18 September 2004 00:43:09 UTC