- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Tue, 9 Mar 2004 08:41:05 -0800
- To: "WS Description List" <www-ws-desc@w3.org>
Web Service Description Group
Minutes, FTF meeting 5 Mar 2004
Cannes-Mandelieu, hosted by W3C.
irc: http://www.w3.org/2004/03/05-ws-desc-irc
Present:
David Booth W3C
Roberto Chinnici Sun Microsystems
Glen Daniels Sonic Software
Paul Downey British Telecommunications
Youenn Fablet Canon
Martin Gudgin Microsoft
Hugo Haas W3C
Tom Jordahl Macromedia
Jacek Kopecky Systinet
Kevin Canyang Liu SAP
Jonathan Marsh Chair (Microsoft)
Jeff Mischkinsky Oracle
Jean-Jacques Moreau Canon
David Orchard BEA Systems
Bijan Parsia University of Maryland MIND Lab
Arthur Ryman IBM
Igor Sedukhin Computer Associates
William Vambenepe Hewlett-Packard
Asir Vedamuthu webMethods
Sanjiva Weerawarana IBM
Umit Yalcinalp Oracle
Observers:
Martin Chapman WSChor
Yves Lafon W3C
Philippe Le Hegaret W3C
Coralie W3C
Paul Biron Health Level 7
Anish K Oracle
In addition to the above observers who were present for most of the
meeting, we had a number of other observers who observed parts of the
meeting.
scribe: Youenn
-------------------------------------------------------
Friday 5 March
-------------------------------------------------------
08:30 Issue 124: Semantics of mandatory properties and features [30]
[30] http://www.w3.org/2002/ws/desc/2/06/issues.html#x124
Tomj: We discussed the proposal and we made some modifications.
Where are they ?
ACTION: Editors to clarify the spec to say that wsdl:required
attribute means that a feature must be understood and
it must be engaged.
RESOLUTION: Issue 124 closed
-------------------------------------------------------
08:45 Issue 149: Duplicate features with conflicting @required [31]
[31] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0208.html
ACTION: Editors to clarify that the strongest value of the
@wsdl:required attribute wins.
RESOLUTION: issue 149 closed
-------------------------------------------------------
09:00 Issue 134: Proposal for adding Compositors [32]
[32] http://www.w3.org/2002/ws/desc/2/06/issues.html#x112
Paul: f&p plus compositors should be modularized
William: Iis the compositor thing reusable in non WSDL space?
[Gudge: +1 from Gudge on modularizing f&p (and anything else that
goes with them)]
[KevinL: +2]
[Gudge: Proposal is at
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0153.html]
Roberto: It would also work outside a wsdl.
[Bijan: Gudge, I've long been in favor of adding stuff as extensions,
but...]
[Gudge: but... ?]
[Bijan: The question is how to do these extensions so that the
proponents are satisfied that it will get the requisite
uptake]
Jeffm: Need more than NANDS, choice, oneOrMore are all interesting
[Bijan: Right now "do it as an extension" == (in most people's mind)
"screw you, it ain't getting standardized". So, there's *no
value* to people in this group in taking what *they* propose
and making it a (separate) extension.]
KevinL: Can we do without compositors in WSDL 2.0? Does it hurt?
[Bijan: I.e., the problem is social, not technical.]
Roberto: Analogy between soap:binding/soap:fault and
f&p/compositors in real cases, soap:fault happens
TomJ: Asked what happens if you don't use compositors Answer:
implicit AND. If we have implicit AND do we need a compositor
for it?]
Umit: Compositors is applicable to all extension space, it is
essential.
KevinL: If the compositor proposal is about composition of extensions,
it is a general idea. If the compositor is only about F&P
it should be considered together.
Sanjiva: Curious that compositors are so critical that it does not
appear sooner.
[KevinL: Continuing what I didn't get a chance to finish - If it's
a general proposal for a new feature, we have been trying
a long time to have a last call, I don't think we want to
take any new features.]
Bijan: What about relationship between compositors and
wsdl:required attributes?
Jeffm: We have more power by introducing it, it is more convenient.
We are picking the minimal set to solve most problems not
all of them.
Gudge: f&p are incomplete. I am surprised that we should add
functionality to incomplete f&p.
Umit: We have a pb with the extension mechanism. this proposal
tries to fix this
William: Does this proposal solve the overlapping problem of f&p?
Glen: No, this pb is too hard.
Bijan: Do implementers feel comfortable with that proposal?
Umit: This proposal came from my product people, they wanted it...
Paul: It would be a pb to have both this mechanism and the
policy mechanism ...
[anish: paul - what is the spec that is in direct competition?]
Glen: I have thought about the implementation of this proposal
and it seems ok. This syntax seems compatible with the
other syntax.
Paul: Analogy policy/compositors and literal/encoded. Have only
one is better
KevinL: Having this in WSDL forces us to implement it. We think
that the decision should be made in another space.
Tomj: The WSDL can become very complex.
Glen: It would simplify things.
[KevinL: What I wanted to say: implementing this in WSDL2.0 force
us to make a choice in a premature manner.]
Jeffm: We may limit the recursivity depths of compositors.
Umit: Two or three levels of nesting are generally sufficient.
TomJ: while on the surface the implementation doesn't seem like
it would be bad, the nesting ability is very worrying
and could introduce many problems.
[Roberto: Technically, aren't two levels enough? we could use CNF...]
[Paul: Want's to vote on moving compositors out of part 1]
Sanjiva: Do you see the need to associate features only inside WSDL
or could it be made outside WSDL?
[pdowney: +1 to no WSDL, no Web service as a notion.]
Jeffm: It is appropriate to use within WSDL because this is
metadata.
[jjm: Glen (responding to Sanjiva): possibly the latter, but at
least the former]
Bijan: Compositors defined as uri, is the extension really needed?
Glen: We could fix this and change the syntax.
Bijan: Could it be done with schema?
Glen and Umit: no
[TomJ: Removing the URIs and replacing with simple values
("and" "or" etc) would make the proposal better in my
view.]
Strawpoll: are you in favour of adding the compositor proposal ?
yes: 7
no: 8
[dbooth: How many cannot live with adding compositors? Yes: 6 ]
[dbooth: How many cannot live with NOT adding compositors? Yes: 3]
[dbooth: Formal vote about adding the compositor proposal to our
spec.]
Philippe: Recaps what is a formal vote. Recaps what is a "feature
at risk."
Vote: adding the compositor proposal in the proposal:
IBM: no
Macromedia: no
Sun: yes
Ccanon: yes
webmethods: no
HP: no
SAP: no
BT: no
CA: abstain
W3C: no
University of m: abstain
Oracle: yes
Systinet: no
Sonic: yes
Microsoft: no
no: 9
yes: 4
RESOLUTION: Issue closed with No Action.
Sun, Canon, Oracle, Sonic plan to file minority opinion.
Sanjiva: Is the primer going within the recommendation process ?
Jonathan: In our case yes
DavidB: This document is not normative, the need to put it in
recommendation track is low.
Hugo: Charter tells us that the primer will be in rec track.
Paul: Part 2 & 3 will have normative data ? Could we have a
normative extension in part 2,3?
Sanjiva: Yes.
[Decide to tackle some issues postponed from yesterday.]
-------------------------------------------------------
09:50 Issue 121: Broken resolution of NCNAME or QNAME [6]
[6] http://www.w3.org/2002/ws/desc/2/06/issues.html#x121
Roberto: Issue is that we do not say that we have
undereferencable namespaces.
Sanjiva: This is an error.
Gudge: What type of error? If we do not use that part of a
WSDL, this is not an error.
All: Yes.
Asir: Schema defines how to dereference qnames. What about
the WSDL spec?
Sanjiva: This is already in the spec.
Gudge: Have we eliminated all NCNAME reference use? If not,
we should.
Sanjiva: I will check the fault section
ACTION: Editors to add clarification text with regards to issue 121
RESOLUTION: issue 121 closed
-------------------------------------------------------
09:55 Issue 92: Layering message patterns [7]
[7] http://www.w3.org/2002/ws/desc/2/06/issues.html#x92
[Sanjiva: Youenn (original proposer) noted that this is now obsolete]
Youenn: This issue is obsolete with the MEP decisions we made.
RESOLUTION: issue 92 closed without action
-------------------------------------------------------
10:00 Issue 133: Why aren't two input/output elements allowed to share
the same @element value? [8]
[8] http://www.w3.org/2002/ws/desc/2/06/issues.html#x133
Sanjiva: We can solve this with a wrapper and a choice element in it.
Tomj: The reason to not allow this is that this is overcomplicated
DavidB: You can do that by defining two operations.
Jonathan: We removed it intentionally as a by-product of the message
removal.
RESOLUTION: issue 133 closed (this is intentional)
[Sanjiva: we note that issue 133 is a by-product of the removing
<message> discussion. If you want to have alternate actual
elements for a message reference (label) of a MEP then you
have to define a wrapper element with a schema and use that.
Alternatively DavidB suggested one could define two
operations and achieve the same result (different input
same output).]
-------------------------------------------------------
10:10 @wsdlLocation
[***** Awaiting proposal from Umit, basically copying
xsi:schemaLocation *****]
[asir: where is the proposal?]
[hugo: Proposal:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0257.html]
Umit: Define an optional @wsdlLocation that would appear in
wsdl:ServiceType in the WSDL schema.
Arthur: You say that you only want one attribute in the service
element. Should it not be a global attribute? We have a need
in policy statements to refer to WSDL components. Then
there is a need to find the description of a component.
Umit: This is a new requirement. My proposal is smaller.
JacekK: In the smaller problem I suggest using wsdl:import instead
of wsdlLocation.
Roberto: We should fix the general pb and consider Arthur's amendment
as a friendly one.
Jonathan: There is an interaction between this and the import
statement.
TomJ: Asks if we add wsdlLocation how does this affect the
<service> element in WSDL?
Answer: Why does it matter? Why do you care?
[GlenD: Still don't get why would anyone care if it's on the
service element?]
[Sanjiva: What are the semantics of service/@wsdlLocation?]
Arthur: I made a proposal (a global element) and you made
modifications on it.
[Sanjiva: And how does it interact with wsdl:import]
[GlenD: It doesn't interact with wsdl:import]
Arthur: There are three proposals in fact
[GlenD: If you've already imported stuff at the top, the
wsdlLocation hint would get ignored. If you refer to
things directly inside <service> which are not yet
imported, wsdlLocation would be used just like it would
in a service reference context.]
Umit: If we follow the global attribute proposal, we need to
define what it is if put in any xml element.
Gudge: wsdl:schemaLocation should follow xsi:schemaLocation.
xsi:schemaLocation cannot be put within a schema definition.
We can put it in soap messages or any xml element.
Roberto: +1 to the global attribute
Glen: This might be an alternate way to import things within the
<service> element only if we follow Umit's proposal
[pvb: xsi:type *IS* allowed in schemas just as any foreign
attributes are allowed. On any element in the schema
namespace]
[Gudge: Gudge would like to know where the serviceType stuff is
in the spec?]
Umit: It is not clear that we can do what schema does, that is
why I have narrowed the proposal. I would be interested
in a text explaining the semantics of this attribute in
any xml element.
Tomj: I do not know what it means to make wsdlLocation a global
attribute...
Umit: Problem is when I have a service reference, I have qname
references and I want to find them
Tomj: When having a service reference, I need to resolve the
references. I do not understand why it is interesting to
solve this response in every place.
Sanjiva: Bpel is a use case for global attributes.
Umit: Bpel and ws-policy are the only use cases for the moment,
which are out of scope.
Sanjiva: Service reference is in the editor's draft in the service
element section.
[Sanjiva:
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html#Serv
ice_XMLRep]
DavidB: Service reference is only in a note.
Sanjiva: It does not need to be normative, you can also do service
reference in other ways.
Strawpoll: should we add some kind of wsdl location somewhere?
yes: 11
no: 0
Jonathan: We will add one of these proposals
Asir: I would like to see an example
Sanjiva: Example of global attribute, inside a bpel when i reference
a porttype it would be convenient to say where to get the
wsdl description.
Jonathan: We would take this attribute in a separate ns, as xsi/xsd ns
Jeffm: Umit proposal is scoped to the service reference
Strawpoll: Would you like to add something along the lines of Umit's
proposal?
9 in favor
strawpoll: Would you like to add something like a global attribute
element?
14 in favor
Arthur: My proposal was modeled along the xsi:schemaLocation, the
semantics are very clear. That is very clear in the schema
spec, we just need to be very clear in the wsdl spec
ACTION: Editors to write in the spec the wsdlLocation global
attribute proposal along what has been done for
xsi:schemaLocation
RESOLUTION: close the wsdlLocation attribute and add a wsdlLocation
global attribute.
[Arthur: Fyi, the wsdlLocation attribute was discussed at the
September f2f where is was called descriptionLocation
http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0219.html]
[Arthur: fyi, example of wsdl:descriptionLocation appears in
http://lists.w3.org/Archives/Public/www-archive/2003Sep/att-0067/01-part
]
-------------------------------------------------------
10:50 Break
-------------------------------------------------------
11:20 Issue 120: Operation Name feature proposal [33, 34, 35]
- Mark Baker had some comments [36, 37].
- Request for being able to detect where the OperationName is
located (Mark Baker) [38]
- First message only, or in responses? (Jacek) [39]
[33] http://www.w3.org/2002/ws/desc/2/06/issues.html#x120
[34] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0082.html
[35] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0152.html
[36] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0173.html
[37] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0175.html
[38] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0105.html
[39] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0165.html
Umit: There is a problem in identifying the operation from the
message exchange (uniqueness on the wire pb)
[dbooth: It seems that this feature is intended to make it easier for
a WS to determine which operation was intended when two
operations use the same input message schema. The separation
of the abstract interface from the binding details provides
a nice conceptual separation between information that is
semantically significant to the application, and information
that is just related to the mechanics of the interaction.
The question of which operation to invoke seems very
semantically significant to the application. Therefore, it
seems odd that such semantically significant information
would not be indicated in the message itself. So I am mildly
not in favor.]
[Umit: The answer to David's question is that if it needs to be
indicated in the message, there needs to be a well defined
place that is defined. ]
Gudge: Along the lines of David, interfaces should have operations
with different messages
[dbooth: Anish, no. I think it's the app's problem if it designs its
message schemas in a way that it can't figure out what
operation is intended. In fact, some apps may choose to
dispatch the operation based on the *values* of the data
in the message, rather than differences in the message
*schema*.]
Youenn: We should at least address the pb somewhere in the spec.
Sanjiva: This is the server's problem, server does not need to
expose how it handles that in the WSDL. What should be
described in the WSDL is what the client should do.
[anish: ok. thx. follow up questions -- what does an operation
mean then? Most people have a certain thing in mind when
they come across the word 'operation'. Are you saying that
operation is just a syntactic construct that does not have
a meaning?]
[pdowney: Wants support for both modes of 'operation' as this helps
him unify document and rpc camps]
Glen: Pb is when someone takes a wsdl for standardization, and
another one implements it. This proposal allows solving
this pb.
[dbooth: anish, yes. An operation is just a syntactic place in the
WSDL document for indicating the message types and MEP.]
Glen: Adding a feature will guarantee that dispatching must be
made in some way.
Umit: This is a pb that has been identified by WS-I. They
constrained the services to have uniqueness on the wire.
Therefore there is a problem.
Sanjiva: This is not a problem for a client (just need to follow
the rules), but there is a problem when a service
implementer picks an existing wSDL. Just need to introduce
a header per operation at the binding level.
[pdowney: Was WS-I a 'solution' or a 'hack' ?]
Hugo: Will the current state spec be profiled by WS-I ?
Jonathan: Even this proposal would be profiled.
Sanjiva: Proposal adds an extension that might need to be profiled.
Glen: But it is clear what the feature does.
Anish: BP put the uniqueness on the wire requirement because that
was a real interoperability problem for web service users.
Sanjiva: The point is that you can solve this problem without
adding a new feature (header, soapaction).
[GlenD: No, David, because that was the original motivation for
the uniqueness proposal.]
Sanjiva: The pb happens when two people implement the same WSDL. We
could say somewhere that if a WSDL writer wants everybody
to implement their service, they need to take care of that
problem with already known solutions.
Glen: The other cases is intermediaries. Intermediaries can see
in the WSDL that it is this header that defines the operation
name.
[Umit: To answer to Sanjiva, there may be multiple ways of doing
this, but not having one way of doing it will lead to
interop problems. ]
[Anish: It all depends on the way you look at it (hack v. solution).
The confining parameters were - WSDL 1.1]
[Umit: We need to limit the choices and define a well-scoped
solution. ]
Glen: Analogy with styles: when i see rpc style, I assert that
the schema is built this way, I can check or not.
Jonathan: I have a service with soap messages and ws-Addressing blocks.
What should I do for my WSDL description? Discussions about
policies, WS-Addressing relationships with features.
Glen: You need to write a new feature spec without changing the
WS-Adressing spec
[umit:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0082.html]
[Roberto: Tasty]
Sanjiva: What is the meaning of required features? Required features
should be part of the WSDL component model.
Gudge: All interfaces will have this feature on/required.
DavidB: We already rejected the uniqueness on the wire constraint.
There is another way to solve this: a style attribute on the
interface. The style attribute saying that all geds
referenced in the interface are different
[DaveO: Sigh. I don't get it. Why make a "property/feature" that
says the uniqueness, why not just make that part of the
definition of the operation. oh well.]
Discussions about relationships between rpc style and uniqueness on the
wire. Rpc style does not span operations and therefore does not really
solve this problem
Glen: The abstract feature says the dispatch info is somewhere in
the message.
[pdowney: Thinks this will kill operations. People will just write a
single operation per interface "stuffHappens" ]
William: What will I need to do if I have an interface with all
message geds different?
Glen: You will put davidB uri in the interface that states that
you are implementing the dispatching feature through unique
geds.
Sanjiva: If we accept this proposal, for each endpoint, somewhere in
the WSDL, there will be an assertion that says I implement
the dispatch through a mechanism. Default value being that
amended rpc style will do that for you.
Glen: Proposal is then that a wsdl writer will not need anything
more if geds are unique and if not, he needs to fix it...
strawpoll: Should we add this uniqueness on the wire proposal
yes: 8
no: 7
Who could not live with the proposal? 3
Who could not live without the proposal? 4
Formal vote: should we add the uniqueness on the wire proposal
BEA: no
Sonic: yes
Systinet abstain
Oracle: yes
Mindlab: abstain
W3C: abstain
CA: abstain
Microsoft: no
BT: no
SAP: no
HP: abstain
webMethods: abstain
Canon: yes
Sun: yes
Macromedia: no
IBM:no
6 no against 4 yes
RESOLUTION: closed issue 120 by not taking any action
[Expect some minority opinions on this one too.]
[KevinL: Is there a 80/20 case? I worry that we are spending too
much time resolving a minor problem. if it's not RPC style,
how much is the chance that two operations refer to the
same message in multiple operation?]
[pdowney: does the same rule apply to telecons ?]
-------------------------------------------------------
12:15 Upcoming FTF:
Next f2f will be from the 19th of may to the 21st of may, thursday
afternoon having task force/informal discussions.
[Jonathan: http://www.w3.org/Guide/staff-contact]
--------------------------------------------------------
12:20 Lunch
Scribe: KevinL
-------------------------------------------------------
13:30 Issue 117: Marking operations as 'safe' [19]
- Hugo's proposal [20]
[19] http://www.w3.org/2002/ws/desc/2/06/issues.html#x117
[20] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0246.html
Continue from yesterday's discussion: marking operation as safe.
Strawpoll: who wants to add to component model for operation safety
yes: 7
no: 3
Formal Vote:
option 1: add new property in component model on operation component.
option 2: introduce an operation safety feature.
[dbooth: (Option 2 means "feature" in the sense of "features and
properties")]
TomJ: Option 1 means make it a top level property of operation,
same level as operation name
vote result:
IBM 1
Macromedia 1
SUN 2
Canon 2
HP abstain
WebMethods 1
SAP 1
BT 1
Microsoft 1
W3C abstain
CA abstain
Oracle 2
UofM abstain
Systinet 2
Sonic 2
BEA 1
Total: 7 for option 1, 5 for option 2
Jonathan: Objections to syntax: an boolean attribute for
interface/operation? Do we need ability to set the value
of this attribute for a set of operations?
[No objections recorded.]
[pdowney:
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/issues/wsd-issues.html#
x117]
[JacekK: http://www.w3.org/TR/webarch/#safe-interaction]
[JacekK: defn of "safe"]
ACTION: Editor to add optional Boolean "safe" attribute to interface
operation, corresponding property in the component model.
RESOLUTION: close issue 117 with action to editor to add an optional
boolean safe attribute to interface operation
[dbooth: WebArch definition of "safe" operation:
http://www.w3.org/TR/2003/WD-webarch-20031209/#safe-interaction]
ACTION: DavidO to notify TAG about or decision
-------------------------------------------------------
14:00 Issue 123: Requiring all operations to be bound [18]
[18] http://www.w3.org/2002/ws/desc/2/06/issues.html#x123
Jonathan: issue from Yaron.
[pdowney:
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/issues/wsd-issues.html#
x123]
[Jonathan:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0115.html]
TomJ: Recaps Yaron's message
PaulD: Is it the case that it's not possible?
Sanjiva: We have already decided not allowing partial binding.
PaulD: Sounds issue is already resolved.
more discussion, just need clarification in spec
ACTION: Editors to further clarify the spec to make clear that
all operations must be bound.
[Gudge: presumably in part 3]
RESOLUTION: Editors to add further clarify the spec to make clear that
all operations must be bound.
-------------------------------------------------------
13:30 Import/include issues
- 127: Behavior if import/include fails [40]
- 128: Two imports for the same namespace illegal? [41]
- 129: Allow multiple values for import/include locations [42]
[40] http://www.w3.org/2002/ws/desc/2/06/issues.html#x127
[41] http://www.w3.org/2002/ws/desc/2/06/issues.html#x128
[42] http://www.w3.org/2002/ws/desc/2/06/issues.html#x129
[TomJ: Issue 127:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0119.html]
[Anish: Isn't the location just a hint?]
Gudge: Question is what if I see import and I don't have a
location?
[Anish: What if the import is being used for a particular binding,
and I don't care about that particular binding? i.e., i
don't process that binding?]
[Asir: If the location is absent, then may be, processor is aware
of those components]
Umit: We should explicitly spec the behavior when location info
is not available.
[pvb: Need to say a little bit on both semantics of import and
in qname resolution...very brief]
[Umit: Correction to scribe: what I am suggesting is that this is
a qname resolution issue, not necessarily whether the import
attempted fails or succeeds.]
Paul: In schema, if import is a failure, many processor just
display a warning,and move on
[pvb: +1 to what Gudge is saying]
Gudge: We already have qname resolution, just need to make it
stronger.
ACTION: Editors to clarify the spec to say that its ok to have bad
imports but if during QName resolution you can't find
something then it fails like any other qname resolution
issue.
[Asir: Is there something called as WSDL document location
strategy (aka similar to schema document location strategy)
in WSDL spec?]
[pvb: A processor which faults when in import "fails" should be
out of conformance with the spec]
[Asir: Schema document location strategy is
http://www.w3.org/TR/xmlschema-1/#schema_reference]
RESOLUTION: close issue 127 by assign editor action to clarify the
spec to say that its ok to have bad imports but if during
QName resolution you can't find something then it fails
like any other qname resolution issue.
[pvb: Does wsdl have chamillion include?]
[Umit: +1 to Gudge]
[Asir: No WSDL does not have chameleon include :-)]
Gudge: Let's say split a namespaces into 3 documents, then import
them,
More discussion on Gudge's case
[Asir: schemaLocation is a required attribute in XML Schema
<include>]
Gudge: Feels inconsistent with the decision we made on import.
[Asir: See http://www.w3.org/TR/xmlschema-1/#compound-schema]
Jacek: Import behaves differently
Gudge: Why do we need to fail early for include?
Tomj: Include is from same ns, import is not
Strawpoll: want to fail include early?
7
strawpoll: want to treat include same as import?
8
[dbooth: Since this would be a constraint on a WSDL processor,
do we want to require ALL conformant WSDL processors
to fail early?]
scribe was too fast to put down a resolution for issue 127 already,
is ready to document a revised resolution
[pdowney: Doesn't want to describe beahviour of a "processor" here
or understand how you would tell if it failed early or
later.]
[Sanjiva: igor: if an included document has a <service> element then
not doing early processing of <include> will break the
world because that <service> will not ever be found]
More discussion if "require" to fail is necessary.
Jacek: We can either make what to include available early or to
allow import from same ns
[pvb: I was wrong, the xs:include/@schemaLocation is required.
But, it says "It is not an error for the *actual value*
of the schemaLocation [attribute] to fail to resolve it
all, in which case no corresponding inclusion is
performed.", in section 4.2.1]
Straw poll: do you want to fail early for include?
10
straw poll: treat include same as import?
6
JacekK: There are two usecases, I suggest solving by allowing
import for the same namespace and early failure for
include.
RESOLUTION: include will fail early (immediately).
[pdowney: how does this fit in with dbooth's work on document (v)
processor ?]
ACTION: Editors to update draft to say that include will fail early.
[pdowney: how do i write a testcase for "fails early" ?]
[TomJ: You include a file that doesn't exists and check for
failure.]
[igors: to scribe: another clarification to my point is that if
one does <include> of a document with <service> tags, then
unless it is mandatory to early process the inclides some
will find those <service> definition and some would assume
they don't exist. Such ambiguity is a problem for the
interop.]
-------------------------------------------------------
Topic Issue 128: Two imports for the same namespace illegal?
Arthur, Glen, Gudge...: You can have as many import from the same
ns as you want as long as they are consistent.
[anish: +1 to Arthur. That would encourage people to do it]
[pvb: Schema includes a non-normative that says just what
Gudge is asking for.]
RESOLUTION: Editor to add to spec to explicitly allow >2 imports
from same ns.
[Anish: Why do we want to encourage folks to do this. It is ok
if they do it, but why encourage?]
ACTION: Editors to add text saying two imports with same
import/@targetNamespace is legal]
Gudge: We should have a different decision for include
Many nos from group
DavidO: Will this force people to design their ns in certain way?
[JacekK: NEW ISSUE: allowing imports for the same namespace as
the targetNamespace of the importing document?]
[Gudge: Gudge, no to Jacek's NEW ISSUE]
[pdowney: Just wants greater clarity on import and include - lots
of work done on this in SB and WS-I and is even more
confused.]
-------------------------------------------------------
Topic Issue 129: Allow multiple values for import/include locations
see http://www.w3.org/2002/ws/desc/2/06/issues.html#x129
[Sanjiva: Proposal change include to: <include
locations="uri1 .. urin"/> and then get the stuff from
whichever URI from that list]
[Arthur: Yaron is proposing a failover mechanism, i.e. if url1
fails try url2 etc.]
Jonathan: Is there a proposal for include to have multiple locations?
Jacekk: How is it different: change include to have multiple
locations, or all multiple imports from same ns?
[Sanjiva: Yes it is different because of the failure rule we have
adopted for include.]
Straw poll: make include a list of uris
in favor 5
no 10
[Sanjiva: no objections to recording consensus]
RESOLUTION: for issue 129: not make import/include take a list
of URIs. close with no action.
-------------------------------------------------------
15:00 Break
[Jonathan: Reminder to self to fix issues 114, 115: proposed
resolution -> description]
-------------------------------------------------------
15:30 Naming issues
- 114: Name of wsoap:fault/@name [43]
- 126: Confusion between binding and element names [44]
- Name attribute consistency
[***** ACTION: Sanjiva to consistify the @name attributes. *****]
Any issues here?
[43] http://www.w3.org/2002/ws/desc/2/06/issues.html#x114
[44] http://www.w3.org/2002/ws/desc/2/06/issues.html#x126
[pdowney: wants to make it editorial and move on!]
RESOLUTION: reassign 114 to part 3
Jonathan: Move on to: is Name attribute consistency an issue?
GlenD: Open an new issue
Jonathan: Keep the action item for Sanjiva
ACTION: GlenD and Sanjiva to come up with a proposal for the new
issue.
[Sanjiva: If no resolution by next Thursday then we will close this
pending action item with no action.]
NEW ISSUE: check name attribute consistency
[dbooth: One possible suggestion for GlenD and Sanjiva: append "Ref"
to names that are references.]
TOPIC: issue 126: Confusion between binding and element names
Gudge, Sanjiva...: It's syntax error, not component.
DavidB: Rename binding:operation to binding:operationRef
options:
1. don't do anything,
2. rename binding operation
Two proposals for renaming: operationRef or bindingOperation
Straw poll:
favor renaming? 7
do nothing? 7
[Lack of consensus, no objections to keeping status quo.]
RESOLUTION: Close issue 126 with no action
-------------------------------------------------------
16:05 Issue 131: Treatment of optional extensions [45]
[45] http://www.w3.org/2002/ws/desc/2/06/issues.html#x139
[Umit: 1+ to Glen]
[Dbooth: +1 to umit: "Who is doing the ignoring?"]
[DaveO: This is why I brought up the issue with Glenn about
"who is ignoring".]
[Sanjiva: Proposed resolution: if an optional extension (i.e.,
an extension not marked as required) is not understood
it MUST be ignored. Any not understood extension
attributes MUST be ignored. (Because there's no way to
mark attributes as required anyway)]
[Dbooth: Furthermore, the service is obligated to support all
features stated in the WSD. ]
[Sanjiva: That is, the WSDL describes the service by definition.]
RESOLUTION: close issue 131 as proprosed and clarified above
ACTION: Editors to add clarification for issue 131
-------------------------------------------------------
16:20 Issue 139: Non-deterministic schema [46]
[46] http://www.w3.org/2002/ws/desc/2/06/issues.html#x139
DavidB: Propose to treat as editorial issue and let editors to
handle it.
Gudge: My proposal in email is the only way to do it.
DavidO: Schema wildcard should work, too.
Proposed resolution: Close issue 139 as Gudge proposed in issue list:
The only fix I can see given the current grammer is to
change the content model of wsdl:definitions to be
<xs:any namespace='##any' minOccurs='0'
maxOccurs='unbounded' />, which doesn't capture any of the
constraints regarding wsdl:include, wsdl:import, wsdl:types,
but there you go!
RESOLUTION: adopt Gudge proposal
ACTION: Editors (namely Gudge and Roberto) to update the schema and
the spec accordingly.]
[DaveO: I may object to the closure of issue 139, pending some
discussions I will have with Gudge.]
-------------------------------------------------------
16:25 Issue 148: Double check URI comparison algorithm and relative
URI use [47]
[***** Needs proposal, possibly based on TAG joint session ****]
[47] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0180.html
Jonathan: Just sent a proposal about an hour ago.
[Jonathan:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0019.html]
[dbooth: +1 to requiring all URIs that are used as identifiers be
absolute URIs.]
[umit: +1 to Sanjiva]
[asir: +1 to Sanjiva]
RESOLUTION: Change all URIs EXCEPT import/@location and
include/@location to absolute URIs at the XML document
level.
ACTION: Editors to change spec to require absolute URIs and indicate
that comparison must be done character-by-character as per
TAG finding.
[jjm: maybe we can also lift the "Use of URI" section from SOAP 1.2:]
[jjm: http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#useofuris]
-------------------------------------------------------
16:40 Issue 115: Improving on-the-wire conformance [48]
STATUS: Resolution proposed at 19 Feb telcon.
[***** Review actual text that gets added to the spec before
closing. *****]
[48] http://www.w3.org/2002/ws/desc/2/06/issues.html#x115
[umit:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0212.html]
Jonathan: Can not close. it's already on editor action list.
RESOLUTION: Schedule for resolution next week.
-------------------------------------------------------
16:45 Issue 135: WSDL Specification readability [49]
[***** STATUS: David Orchard to produces a specific example of
the kind of change he envisions. *****]
[49] http://www.w3.org/2002/ws/desc/2/06/issues.html#x135
Jonathan: Need proposal for example changes. Plan to produce last
call with resolutions from this F2F incorporated. Can not
wait until May F2F. In light of that, if we don't see
example by thursday, will be left out last call
RESOLUTION: schedule for resolution next week based on proposed examples
-------------------------------------------------------
16:50 Issue 104 Appendix E cleanup (using alternate type systems) [50,
51]
- Bijan's review [52].
- Might want to add OWL support to appendix E
[***** STATUS: Awaiting concrete proposal from Jacek and
Bijan (does 143, 144, 145 cover it?) *****]
[50] http://www.w3.org/2002/ws/desc/2/06/issues.html#x104
[51] http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0136.html
[52] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0182.html
[Sanjiva: closed with no action as subsumed by other issues]
RESOLUTION: close issue, covered by other issues.
-------------------------------------------------------
16:55 Issue 97: Schema language for SOAP encoding [53]
- Proposal from Jacek [54]
- Address comments from reviewers (Paul, Asir)
- Decide on disposition: Chair recommends a Note.
[*****ACTION: Paul and Asir to review the SOAP Data Model
Schema. *****]
[53] http://www.w3.org/2002/ws/desc/2/06/issues.html#x97
[54]
http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/att-0098/SOAPDat
aModelSchema.html__charset_ISO-8859-2
ACTION: Asir will send comments to list.
RESOLUTION: reassign issue to part 3.
-------------------------------------------------------
17:00 Issue 106: Using RDF in WSDL [55, 56].
[***** STATUS: Dependent upon RDF mapping first draft, need to
figure out how to get unblocked from going to Last
Call. *****]
[55] http://www.w3.org/2002/ws/desc/2/06/issues.html#x106
[56] http://lists.w3.org/Archives/Public/www-ws-desc/2003May/0076.html
RESOLUTION: reassign 106 to RDF mapping
-------------------------------------------------------
17:02 Issue 111: Simplified syntax? [57]
[57] http://www.w3.org/2002/ws/desc/2/06/issues.html#x111
RESOLUTION: Close issue 111 with no action
[dbooth: Reason for closing issue 111: Given that nobody has changed
their mind about wanting this, DaveO has withdrawn his
proposal.]
-------------------------------------------------------
17:05 Next steps towards Last Call
- How to close any unresolved issues.
- When will we see the first internal Last Call spec?
- Process for reviewing and approving Parts 1 and 2.
- Ramping up on Part 3.
Jonathan: Schedule telcon for next Thursday to close more issues.
Two weeks from Thursday, see a draft with resolutions
incorporated. From now, move bar higher for adding
issues to part 1 and part 2. Criteria for new issues
for part 1 & 2 : must be accompanied by a concrete
proposal. Once we hit the 0 bug bounce for part 3, we
will revisit remaining/new issues for part 1 & 2
Umit: What to do with media type document?
Jonathan: We have a proposal but haven't adopted by the group so
far. We can do it now, or ... Two parts of that, one
in instance, one in schema. How do we adopt it as a
wg deliverable?
Umit: Assign action item with date
Anish: XOP has dependency on this. Schema part belongs to WSD
WG. Instance part can go either way. But instance part
is related/dependent on schema part.
Jonathan: How will we get this into our process? Suggest adopting
as a note.
Sanjiva: We may need to involve schema group.
Jonathan: Not yet.
Sanjiva: Worry about time line.
Jonathan: This is something we removed from WSDL1.1
[DaveO: Why a Note?]
RESOLUTION: Adopt Umit proposal as a base for a note on representing
media types in schema.
Anish: Anything to report to XMLP WG?
Jonathan: Will send a note to them, asking them for volunteering
editors.
ACTION: Jonathan to send a note to XMLP, asking them for
volunteers for editors.
[JacekK: DaveO, what else?]
RESOLUTION: Umit appointed as WSD WG Editor on note.
ACTION: Editors of media type proposal to give Jonathan a list of
open issues.
Jonathan: HTTP binding issue planed for next Thursday call
Hugo: Request to move http binding for week after next week
Sanjiva: Is concerned about the status of the RDF mapping of WSDL.
Jonathan: Nice to have a working draft. If not already done so, I
appoint Bijan as editor of RDF mapping.
[pdowney: has a stong interest in the RDF mapping: it assists formal
testing of processors, decentralised discovery, and
composition of legacy Web services ]
RESOLUTION: Bijan appointed as RDF Mapping editor.
Jonathan: If no request from people, and if nothing for agenda next
on, will randomly select part 3 issues to put in agenda.
18:00 Adjourn
Received on Tuesday, 9 March 2004 11:41:41 UTC