- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Wed, 4 Feb 2004 09:49:56 -0800
- To: <www-ws-desc@w3.org>
Web Service Description Group
Minutes, FTF meeting 30 Jan 2004
Bedford, hosted by Sonic.
irc: http://www.w3.org/2004/01/30-ws-desc-irc
Present:
David Booth W3C
Roberto Chinnici Sun Microsystems
Glen Daniels Sonic Software
Paul Downey British Telecommunications
Tom Jordahl Macromedia
Philippe Le Hégaret W3C
Kevin Canyang Liu SAP
Jonathan Marsh Chair (Microsoft)
Jeff Mischkinsky Oracle
David Orchard BEA Systems
Bijan Parsia University of Maryland MIND Lab
Arthur Ryman IBM
Adi Sakala IONA Technologies
Jerry Thrasher Lexmark
William Vambenepe Hewlett-Packard
Umit Yalcinalp Oracle
Phone:
Allen Brookes Rogue Wave Software
Amelia Lewis TIBCO
Jean-Jacques Moreau Canon
Sanjiva Weerawarana IBM
Prasad Yendluri webMethods, Inc.
Regrets:
Youenn Fablet Canon
Jacek Kopecky Systinet
Ingo Melzer DaimlerChrysler
Jeffrey Schlimmer Microsoft
Igor Sedukhin Computer Associates
scribe: William
-------------------------------------------------------
Friday 30 January
-------------------------------------------------------
09:00 Binding issues:
- Issue 80: Inappropriate binding component name [30]
Options:
a) Yes: come up with an alternative name.
b) No: close issue
- Issue 82: Relax binding syntax [31]
Need proposal to understand the scope of this issue.
- Issue 83: Interaction between binding extensions [32]
Options:
a) In scope: come up with a proposal.
b) Out of scope: close issue.
[30] http://tinyurl.com/ysgl#x80
[31] http://tinyurl.com/ysgl#x82
[32] http://tinyurl.com/ysgl#x83
Deferred
-------------------------------------------------------
09:15 Issue 109: Versioning [33]
- Required reading (DavidO) [34]
- Use Cases (DavidO) [35]
- Requirements (PaulD) [36]X
[33] http://tinyurl.com/ysgl#x109
[34] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0098.html
[35] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0070.html
[36] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0076.html
Paul: 2 tactics possible. You use 2 different descriptions but
then you get stuck with 2 documents and 2 pieces of code
jeffm: what kind of changes are you talking about?
paul: eg "getCustomerDetails" can grow in a backwad compatible
way: we get and send more info. An existing client may
ignore it, or dynamically accept it (like display it)
without understanding it
glen: that's an xml pb
paul: Schema is trying to define the whole doc. You have to know
from the fact where you'll want to add element, using usually
xsd:any. This causes all kinds of pb. if you ignore things
that were not in the schema that leads you into pb.
Basically all I am asking for is the ability to add
something to a service and not break clients. And if schema
is not good enough, maybe we can do something in wsdl.
jon: There is a schema/message question. but also changing the
description (like adding operations in the wsdl)
paul: backward compatibility is ignoring info. Forward
compatibility is defaulting
jeffm: You are talking about adding something that "doesn't beak
the semantic". what does "break the semantics" mean? it's
ap-specific. When i assert that the service i deploy is
version B of version A, what am i saying? sometimes saying
that something is the new version of something else is
just a marketing statement
daveo: Why not give a tool to the app developer so that whatever
they mean by "next version" they can express that
jon: Let's start at the bottom. paul provided a specific example
of need. what can we do to help?
jeffm: We have to be very precise about what we are defining
daveo: Are you looking for a definition of compatibility?
jeffm: Yes
roberto: A wsdl is exposing a service with a particuar endpoint.
That doc is a contract between client and server. A newer
version of a contract would be such that if the client or
server is updated the same assertions (that were in the
old wsdl) are still valid. These are the wsdl assertions.
Other asertions are part of the app but like jef i don't
think we should go there.
arthur: One of the uses is to add more info but not add the client.
There is a technique in ADO.Net where the first part of
the message is the schema and the second is "any" so the
schema is determined at runtime. So you can design a
client that takes runtime type info in you want.
paul: Sounds a bit like xsi:type.
[umit: This method implies that there is no document contract
between the client and the service. ]
arthur: Or you can use name/value pairs in the message. Like
properties
paul: This is crucial to us users of web services. if we can't
change our web services it's going to be a reason for not
using it
arthur: COM took the attitude that itnerfaces were immutable. if
you want to add something you add a newer interface. so
existing clients didn't break
[DaveO: http://www.w3.org/2001/tag/doc/versioning-20031003#terminology]
Arthur: That enables 3rd party component markets. Web services
could take this attitude and this would permit a more
orderly evolution, and not force everyone to update at the
same time.
roberto: But interfaces were defined by the framework provider
arthur: No, you can buy bags of widgets (like calendars) and the
interface is written by the component provider
roberto: The majority was things like iDispatch that used late
binding.
arthur: w/ wsdl the implementation is completly opaque, you only
see the interface. so there is no such thing as minor/major
change
tom: +1 to arthur. when you are changing the interface it's a
new service. i don't see what we can do. is there a
proposal on the table? i think the only thing we can do
is to add something showing the "version" of the interface,
that's all
jeffm: trying to understand what the requirements are. You have
to define "A is a version of B if and only if...(what?)"
umit: paul is after data evolution, not just adding a new
operation to an interface. schema hasn't correctly
addressed this pb. we need to separate the wsdl pb from
the schema pb
paul: I am asking for 3 things: the data on the wire to be
versionable, to be able to change the interface (add
binding, operation) and finally to be able to communicate
about the changes (are they backward compatible, are they
major or minor changes...)
kevin: How about changes in the WSDL file that don't impact the
interface? for example change in the copyright statement?
How do you do that? same targetnamespace but differnt text?
arthur: There is some work in OASIS on this
jeffm: Many of the things paul are asking for are not possible.
The only way to progress is to define constraints on what
you want to do here
jon: We need a concrete list of pb we want/can solve so we can
go out and see if we can have proposals on these specific
things. make the discussion more concrete. The 3 things
we might want to support are:
1- change (evolve) xml on the wire
2- adding to the interface
3- communicating changes
daveo: This stuff is in the web arch doc. (how to use namespaces
for such things). If you use a mutable namespace name,
you might want to specify what changes are possible
williamv: The WSDM working group is working on providing support for
relationships between resources. that can include
interfaces. and relationships in the "change" category,
such as compatibility
arthur: Another approach is to use interface inheritence
[Recapitulation we've listed 3 ways to address the 3rd requirement
(communicating changes):
namespace,
WSDM relationships,
inheritance]
arthur: When you are adding a new operation, the clean way is to
create a new interface that extends the old one
daveo: the "namesapce" approach is really namespace plus version
attribute
arthur: Generating a new interface is not going to break the
client. otherwise you are going to break the client.
[arthur/roberto discussion on what in JAX-RPC would or would not
break the client (in terms of changes to the interface)]
arthur: If new interface is binary compatible with the old (because
you only added a new operation) then the old client would
still work. the trouble would be for the server side. From
the server point of view, if some organization is creating
an interface and later wants to add a feature, the client
needs to keep both implementation. a server built to the
old interface will no longer work
roberto: Yes, the case of the server is different
arthur: It's cleaner to use inheritence to add new operations
paul: This is not just "BT's pb". it's something we have a lot of
experience on, but it's a platform pb
daveo: You can work on the schema itself that controls the content
of message and then there's the schema language. and the
there's the interpretation of the schema results. e.g. you
can have a validation mode that doesn't stop when you see
=something you were not expecting. And then there are
wsdl-specific things. all the constraints defined by wsdl.
The part about changing wire stuff is getting more
understood. Maybe there is something the wsdl group could
do in terms of how it uses schema.
paul: Wsdl 1.1 has support for array, taking schema and annotating
it. We can do a similar thing.
daveo: a common model is to use xsd:any with another namespace. But
this forces you to predict where the extensibility is going
to go.
jon: Is there a way to specify in wsdl how to validate the schema?
additional rules?
daveo: You can mark the new type and say how it is part of the old
type. Or you can do "validation by projection". Where you
only validate what you understand. Schema does not have a
way to constrain what a wildcard can be used for. All it
has is namespace constraints.
jon: We might be able to get schema to add another attribute to
xsd:any
umit: Not sure you can do this by extending xsd:any
glen: This is good discussion, but this portion of the discussion
is endemic to schema and xml at large and we might better
use our time talking about how we can deal with wsdl object
model changes
daveo: wsdl uses schema. you can varry the way it uses it. You
can't ignore a new operation invocation, but you can ignore
a new element in the xml on the wire (response to a
suggestion from glen to focus on changes to the wsdl doc)
jon: The psvi annotations everything. doesn't get a pass/fail
to the whole doc. we could look at the psvi and say "if
you failed validation, here are other steps you can take"
paul: So validation is not pass/fail, it is something you have
to process to turn into a global pass/fail. Opens the door
for us to tell wsdl processors how they interpret results
from the schema processor
umit: you usually don't have access to this info in the tools i use
daveo: That's the kind of thing i am thinking about. In late binding
kind of system you're more able to deal with these changes
of wire format.
jeffm: if you use statically generated code you can't adapt. unless
you build extensibility into the processor. One way is to
say "if you use the following guidelines and uses to design
your schema you can expect these extensions to be possible".
We could provide such guidance
daveo: What is the farthest you can go with default validation and
schema as it is today? this takes us somewhere but it is
not that great a place. this group, within the group, has
the ability to take us further. it could also exert
pressure on the schema group
arthur: The crux of the matter seems to be that you want to add
something to the message (like frequent flyer number) and
not have the client do. what do you want the client to do
with it?
paul: ignore it?
arthur: ok, what else? if all you need is to add data so that
people can ignore it, what's the point?
paul: Some client will ignore it. but the whole point is that
some might know how to make use of it. Schema has led to
a mindset about how to use web services. Another view is
to use query languages, where the code queries the XML for
the info it wants. additional information would not break
this kind of implementation
arthur: In certain apps where the client doesn't really understand
the data (like it only displays it) you can design a very
lax message standard. In the cases where you really expect
someone to process the info, a more tight message format
is appropriate to allow the app developer to look at the
message format ahead of time
paul: When you have a large community of clients, versioning is
critical otherwise you can never change anything
jeffm: We need to write a description of a language and processing
system that has to work for everybody. what you have in
mind (talking to Paul) is a specific set of usage. assuming
this kind of usage is important enough that we need to
worry about it, we need to clearly define this set of
applications so we know what we're talking about. Also,
certain pbs where solved in Corba even if there was no
market uptake and we need to look at how these were solved
there. Also, there is a way today to do what Paul asks for.
use getXML/setXMl operations if you don't want to use a
schema that tells you what the format will be. In order to
put "backward compatible" in a spec it needs to be defined.
daveo: Schema and the way we use it (and wsdl) has guided people
to think about how they use web services in a certain that
has led to more brittle systems than needed. Language A is
compatible with language B if all the things valid in B are
valid in A
daveB: And have the same meaning
daveo: From a set theory perspective, you have a known set of
things and an allowable set of things. when you go to the
next version, things are moving from allowable to known and
known is getting smaller. these two sets are converging
through the successive versioning. Can't think as server
and client. need to think as server and receiver
jon: we'll take a break and then we need to look at concrete
proposals to pursue. 20 minutes break.
10:50 Break:
11:15 Versioning (cont.)
jon: Need to become specific.
arthur: There's nothing about WS that forces brittle systems. you
can have very weakly type interface declaration. Having a
contract gives implementation freedom
daveo: If you give the interface writer the ability to say how
to handle things you don't know (as part of the contract)
then you don't loose the benefits of providing interfaces.
Schema 1.1 is not going to be a usable option for maybe 5
years. maybe there is something we can do in wsdl. in the
way we use schema, that would enable this operation
arthur: awaiting proposal from daveO
roberto: 1 approach (heavy weight) uses subintefaces, version
identifiers, multiple parallel endpoints, etc takes a
large amount of work and discipline but it works. this is
doable and we don't need to say anything. people who know
how to do this don't need our help. The lightweight
approach for the ordinary guy with simple needs. we can
give advice for this. e.g. "you can add operations but
not remove them", "you can extend schema in a compatible
way"... etc. only to preserve on the wire compatibility.
this is tractable. For the larger pb as addressed in
dave's paper, there are lots of pbs that need more time
to be addressed. Not opposed to having this in an
appendix rather than the spec itself.
daveO: I think we should tell things to wsdl authors about what
they can do with schema. i want to make a proposal about
that. How "validation by projection fits into the wsdl
model. I'd like to make a more concrete proposal in terms
of what wsdl 2.0 can do to use an augmented form of
validtion. Short of that all we can do is give advice but
even then the WSDL authors are not in a very good place
roberto: Where would the proposal go in terms of our deliverables?
daveO: Allowing people to express how they want to use the
schemas they import or include
jon: Would there be an affect of schema components?
daveO: Maybe we'd make fuller use of what schema provides
jon: You would put soemthing in the spec that says "the way
the schema describes a message doesn't describe all the
structure of the message, there might be other stuff"?
Would it involved respecifying schema?
daveo: Hope not. if it involves a huge amount of effort just
forget about it. Permission to proceed?
bijan: How modular is this proposal or issue? does it require for
technical reasons text in the core spec or could it be
separated?
jon: sounds core to me
daveO: right now we are not really using all the data that's
provided to us by schema validation
jeffm: seems like there's going to be 2 issues to deal with:
the technical soundness of this approach and the level
of work it is going to impose and how that fits into
schedule.
daveO: Why don't i write up a bit more and we can take a look at
it after it hits the mailing list
umit: what you are talking about is a new extensibility model for
schema
jon: Does this pb manifest itself in relaxNG
daveO: relax has an open contact model
DaveB: pb goes away if you use RDF
daveO: we could punt on it, listing things you can't do because
of schema and point people to other schema languages than
XML schema that do not have this limitation. A differnt
interpretation of schema validation result allows us to
do the kind of things people are trying to do.
jon: Another approach is to say "these are our requirements
for schema 1.1"
daveO: This is a separate track. Schema group is interested, but
that's years down the road. In other groups with possible
dependencies the model has been to do the work in house,
not wait for external dependency
jon: Is the best solution for schema to provide us with an
open content model?
daveO: We need to explore this. too early to say there is one
path forward.
phillipe: Now would be the right time to give reuirements to the
schema group as they are going to have a new charter
written soon.
jon: DavidO will write a statemetn describing what we'd like
from schema. Some aspects are more important than others.
being limited on location of extensions is not a big
deal. being limited on how many times you can extend is
a much larger pb
daveO: We want to be able to do multiple revisions. that would
require changes to schema 1.1 which has a certain time
frame. a certain interpretation of schema gives you that
feature in a shorter timeframe and under our control.
jon: not sure that's possible, we need to see that in more
details
daveO: multi-direction approach: talk to schema folks, give
advice to people and things we can do in terms of our
language
jon: how do people feel about the proposal to interpret schema
differently? if we are not interested we should let daveO
know before he does all the work
arthur: what are the implication of us reinterpreting schema?
wouldn't the complete rewrite of al XML tools sink wsdl 2.0?
daveO: Premature to answer this question
arthur: Part of being a good solution is wokring with existing
technology, so i will be looking for this is daveO's
proposal
jeffm: We'd have a hard time accepting this if it means we can't
use off the shelf schema processors
daveO: I'd be interested if you asked customers what they would
trade off. if it required a change to takes X amount of
time, wold they accept the trade-off
jon: The question is, if we can't do this without affecting
schema should we do it anyway or give it to the schema group?
People want to move a schema between WSDL processors and
other processors. We're not hearing people it's a bad
thing to explore this proposal, but there is resistance
to do something that can't be layered on top of an
existing schema processor. We also want to write up a
request to the schema group to see whether they can
address this functionality. maybe talk with them at
the plenary
ACTION: DaveO to write up a proposal for augmenting schema
information to enable versioned data.
[umit: the problem is having different schema processors. A
document which is valid differently when validated
using WSDL and some other tool will confuse customers.]
jon: Finally, the last part is a set of remarks and
recommendations for our users
roberto: Where would this go? appendix?
ACTION: DavidO to write request to schema group
jon: Adding binding and additional optional extensions (or
schema) should not make them incompatible
glen: The pb is that you can no longer think about things
based on the metadata you understand. Add guidance as
best practice to use extension to add an operation to
an interface.
arthur: What about addition of an outbound operation? won't
this break the client?
roberto: in this case, this is not a client on the wire.
daveO: Need to talk in terms of senders and receivers
glen: Maybe we should introduce a well-known "the xml you sent
me did not match what i think i am supposed to expect to
receive" as a fault, a subcode of sender fault.
WilliamV: From a mgmt perspective you want to be able to create
relationships between different things, you don't want
them to appear as the same thing otherwise you can't
express "A is compatible with B"
jon: Big question is do we want to say things about how you
do versioning
daveO: We might need a way to express a WSDL version attribute
to distinguish different versions of a wsdl
tom: Sometimes you need to tell customers "schema makes it
hard to version data, so as a result in wsdl you create
a new itnerface to version"
[KevinL: +1 to paul about versioning is critical for services with
LARGE user base]
glen: "if you want to add an operation, you need to define a
new interface, unless you are doing this at dvpt time at
which case anything goes" (proposed best practice)
jon: Evolving towards a section in the primer. Can someone
write it up for david to include in the primer? Last
question, do we want to add "version" metadata to the WSDL?
tom: Makes proposal to add a version attribute to the interface
component with a "major" and "minor" component, where major
means incompatible change and minor means compatible change
daveO: I'll lie in the road before we use minor and major versions.
URIs are there for that. I agree with minor version
identifier but major version is a change in URI
bijan: Why are 2 URIS where version and namespace are tied are
better to 3 URIs, which links to Tom's proposal. Is the pb
with Tom's proposal that he didn't use URIs for versions
or that he separated version from namespace?
jon: Need someone to wrie a counter proposal to Tom?
daveO: if adding a version attribute would help and we need
someone to write it i can do this
tom: I can write up some syntax on the proposal to add a
"version" attribute. If people feel strongly that we need
URI rather than integer then we can discuss it
umit: We should not limit this to the interface
kevin: Move it to the "description" element
roberto: What if i computed a hash instead of looking for the version
number
tom: Willing to change the proposal to move this to the definition
element
umit: Schema defines a version attribute
roberto: We need to see some writing so we know what this attribute
is to be used for exactly
ACTION: Tom to write proposal on version attribute
12:30 Lunch
-------------------------------------------------------
13:30 Issue 96: Support for SOAP intermediaries [37]
Need an analysis on whether there are issues here.
[37] http://tinyurl.com/ysgl#x96
Deferred.
-------------------------------------------------------
13:30 Inheritance issues:
- Issue 76: Pointing at derived interfaces [22]
Options:
a) Yes: need volunteer to write up a proposal.
b) No: close issue
[22] http://tinyurl.com/ysgl#x76
Is it ok for an endpoint to point to an interface derived from what
is expected? 2 cases in which this happen is when endpoint in a
service element and endpoint reference also gives you expected
interface.
Glen & Jonathan: looks ok...
Glen: In both cases, you can send the messages, so I think it's
fine.
Arthur: The question: can you allowed the endpoint to point to a
more derived interface than the one referenced from the
binding? (or the other way around)
Glen: You can have a binding without an interface, with
operations inside. (reusable binding)
[TomJ: I think the status quo in the spec
(endpoint->binding->interface must match service->interface)
is the right thing.]
Arthur: I think that the interfaces can be subtitute
Roberto: Don't think we should do it. they are around. no need to
complicate the spec.
Glen: what about the case of dynamic reference? If I don't have
a binding for the derived interface but just have one for
a derived one....
Tom: I'll have to do a lot more work now. traversing the
hierarchy interface, ...
Arthur: I think the case as a meaning and would be a simplification
for authors (you don't have to create one binding per
interface in the hierarchy)
Umit: We never discussed the idea of having @wsdlLocation. I can
write a proposal along those lines
ACTION: Umit to write a proposal on @wsdlLocation
Arthur: We had a proposal and it got shot down. wsdlLocation would
be a global attribute, just like schemaLocation
on the service references. You would use it anywhere.
(clarification on the use of xsi:schemaLocation)
(wsdl:descriptionLocation? )
Proposal to close the issue 76 without action
...
Jonathan: no compeling scenario to allow this
RESOLUTION: issue 76 closed.
-------------------------------------------------------
13:45 Issue 81: Account for interface inheritance [23]
Options:
a) Yes: come up with an alternative.
b) No: close issue
[23] http://tinyurl.com/ysgl#x81
same as 76?
[Marsh: Resolution: issue 76 closed as dup of 81]
[Marsh: Resolution 81 closed without action, no compelling
scenario and workaround exists.]
-------------------------------------------------------
14:00 Issue 95: service/@name required? [20]
Options:
a) No: remove service/@name
b) Yes: close issue.
[20] http://tinyurl.com/ysgl#x95
Glen: We want people to use when they believe they will refer
it outside the context of the wsdl. It makes sense to have
anonymous service. service is top-level. it does not
necessarely need a name.
Roberto: Didn't we say that every component must have name?
Umit: If we don't require a name, we will have troubles with
equivalence of components. you only compare components with
name/qname.
Roberto: No, you would fallback to the default definition of
equivalence. all properties must be equivalent.
Tom: In a wsdl documentn, a service element must have a name, but
it's the schema, it must be marked as optional.
Joanthan: If it's NOT a child of definitions, it's optional. otherwise
it's required. but we cna't express that in the schema.
Glen: what about a base type of service serviceBase, then an
extended one with a required name?
Umit: For a service reference, the proposal is to use a service
type, not a service element. (minutes were incorrect. there
is a typo in it)
Arthur: You can make the attribute optional in the base type. and
then required in the element declaration.
Tom: A service reference can then contain a random string in
the required name...
Umit: it's not an issue
Bijan: So, make it optional or use a schema trick? (as Arthur's
proposed)
Glen: We don't prescribe THE way to make service references. other
solutions are not precluded.
Umit: You're forcing people to derive from the base type.
Tom: We had a compromise to have it optional in the xml schema
and make it required in the wsdl spec
Umit: I don't want to revisit the ServiceType
Adi: I don't see why we should different ways between the wsdl
schema and the wsdl spec
Bijan: If the constraint can't be expressed in schema, I would
favor the approach of having it optional in schema and
required in the spec. oterhwise, let's make it required.
Umit: You have 2 choices and 2 differents types top derive from.
One with a name, one without.
Jonathan: How can you derived from the anonymous type? Can we do
editorial changes without modifying the previous decision?
RESOLUTION: @name optional for the standalone service type use. it
will be required inside the context of a wsdl document.
we may be able to describe in the schema as well as in
the spec but we should check for side effect.
Umit: There is a derivation issue we should look into
ACTION: Jonathan to correct type in last f2f meeting on _S_erviceType
RESOLUTION: issue 95 is closed
-------------------------------------------------------
14:30 Media type TF report (preliminary) [41]
[41]
http://lists.w3.org/Archives/Public/public-ws-media-types/2004Jan/0001.h
tml
Umit: No interest into the media types TF and shame on us :)
There is a document that needs to be reviewed!
Jonathan: The proposal should be taken to the group and gets
reviewed there. Or we can delay a bit until we look into
MTOM?
(a bit of history on media types in WSDL)
ACTION: Umit to forward a link/proposal on media types to the WG list
-------------------------------------------------------
16:30 Issue 104: Appendix E cleanup [43]
[43] http://tinyurl.com/ysgl#x104
Bijan: clarifies that his issue 104 is about message and
messageReference. it's a consequence of appendix E, but
not about the appendix itself. You can
input/@messageReference as well as @input/@message.
The qname that points to a message type has to be an
element. If you're using a non-XML type system, you're
screwed. The spec says that a message has to be an
element declaration.
Roberto: No, a schema element declaration, or something else.
Bijan: So any alternative type system has to use an extension?
Jonathan: Yes. You need to define an other element that would
describe schema specific way to point to the schema
construction.
(Roberto quotes 2.4.3)
[[ The element declaration resolved to by the value of the
message attribute information item if present, otherwise
a similar construct in some type system as referred to by
some other attribute information item if present,
otherwise empty. ]]
Tom: Message points to a GED
[@message vs @element ?]
Tom: Let's say we picked one to follow WSDL 1.1
[TomJ: Changing the name of the input/output message attribute to
element is consistant with WSDL 1.1. In WSDL 1.1 there was
a problem with type vs. Element in <parts>. If we pick
element, we can say to users, we picked one - element.]
RESOLUTION: General acclaim to rename @message to @element
ACTION: Jonathan to add s/@message/@element/ on a teleconference agenda
Bijan: What about messageReference then?
@messagePosition, @mepPosition, @position?
messageReference doesn't reference a message. so it's
not a message reference. it refers to a position in the MEP.
Amy: It points at the name of the message, not to a position.
Tom: In the request-response MEP, you can call the messages "in"
and "out"
Glen: or "request" and "responses"
Roberto: how about @label?
Glen: @messageLabel?
David: @mepLabel?
Glen: <input element="?" label="?" />
RESOLUTION: General acclaim to rename @messageReference to @label
ACTION: Jonathan to add s/@messageReference/@label/ on a teleconference agenda
15:00 Break
-------------------------------------------------------
15:30 Binding issues:
- Issue 80: Inappropriate binding component name [30]
Options:
a) Yes: come up with an alternative name.
b) No: close issue
[30] http://tinyurl.com/ysgl#x80
David: A bind does no longer bind, so the name is inappropriate.
transport?
Bijan: Grounding?
Tom: Binding is well established.
David: But misleading
Tom: Only to people who really thinks about it :)
David: The binding tells the encoding (message format), and the
protocol. How about serialization?
Jonathan: The binding binds the abstract to the protocol level
Adi: You still do the binding in any case
David: But the binding can happen at the service level. The piece
of information which is adding is the protocol
Glen: You can bind the same interface to 5 differents SOAP
bindings. So it's not a protocol.
[alewis: I think "binding" is a term of art in WSDL, and changing it
is not going to help.]
[KevinL: +1. I don't see the benefit worthes side effects on, for
example, backward compatibility with wsdl1.1]
Glen: The association is made with a place holder. the real
interface might be given at the service level, but you
still have a place holder.
RESOLUTION: let's keep "binding", close issue 80 with no action
-------------------------------------------------------
15:45 Issue 82: Relax binding syntax [31]
Need proposal to understand the scope of this issue.
[31] http://tinyurl.com/ysgl#x82
"When all is said and done, the semantics for a combination of binding
info pieces must be consistent and reasonable. We should consider not
using so many syntactic constraints to make that happen."
Glen: Claims that he didn't write this :). Maybe related to
defaults in the binding?
RESOLUTION: given the changes to the syntax, we close issue 82 with no
action.
-------------------------------------------------------
15:50 Issue 83: Interaction between binding extensions [32]
Options:
a) In scope: come up with a proposal.
b) Out of scope: close issue.
[32] http://tinyurl.com/ysgl#x83
"What is the interaction between binding extensions? Is it out of
scope of Part 1, which appears to be the status quo? We should be
explicit, especially if we define any sort of composition
mechanism across bindings."
Glen: Still claims he didn't write this :) Extensions must make
sense when they're composed.
Joanthan: we don't have inheritance. so no composition
RESOLUTION: Issue 83 is closed with no action.
(Jonathan reviewing the issues list for open ones)
-------------------------------------------------------
Issue 92?
-------------------------------------------------------
Issue 113 is mistitled
ACTION: Issues list editor to retitle Issue 113.
-------------------------------------------------------
Issue 91:
(title is misleading)
Part 2 is now talking about Message Exchange patterns, instead of
Message Patterns
DavidB: our MP are now aligned with WSA, so let's change the
terminology.
RESOLUTION: Issue 91 is closed, editors will use the term "Message
Exchange Pattern" rather than "Message Pattern".
-------------------------------------------------------
Philippe raises an old issue which he doesn't see on the issues list:
"Flagging an operation as 'safe'"
Philippe: two parts:
- indicating that the operation is safe as defined by HTTP
so the operation is considered as-is independently of
the underlying protocol.
- changing the default POST binding of SOAP 1.2 to a GET if
possible
Tom: I don't remember liking this idea...
Bijan: If you didn't mark an operation safe and it uses GET, what
happens?
Philippe: [...]
Tom: complexity, harder, etc....
(some clarification on SOAP 1.2 binding and the webMethod property)
Glen: You can use the webMethod GET at the interface level to
express that.
David: But you can have other safe operations that are not GET.
Tom: When you say something is safe in WSDL, it doesn't mean
anything.
Philippe: If the operation is safe, you can do more assertions about
the reliability (repeat the messages, ...)
Glen: You can use a property for that?
Bijan: It will make a large class of web people happier. it's
possible it will improve efficiency, ... on the side, if
we make into an extension, and it is popular, it will be
used. My preference is to make an extension.
Bijan: Make your extension a note and see if it's use.
Jonathan: Is there anything else we want to put into that note?
Philippe: Not as far as I know
ACTION: Philippe to draft a note for the group around safe operations
-------------------------------------------------------
New (old) issue: "renaming the label of MEPs"
in/in-out: A can be request, B can be response.
Amy: we have several in-out MEP: in-out, robust-in-out, and
maybe in-optional-out
in HTTP, if no out, you get a 200 code.
Amy: Suggest to change A and B to IN and OUT and we open an issue
asking if we should be more colloquial for the labels
RESOLUTION: Change MEP labels from A and B to IN and OUT
17:00 Adjourn
Received on Wednesday, 4 February 2004 12:51:07 UTC