- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Tue, 9 Mar 2004 08:40:30 -0800
- To: "WS Description List" <www-ws-desc@w3.org>
Web Service Description Group
Minutes, FTF meeting 4 Mar 2004
Cannes-Mandelieu, hosted by W3C.
irc: http://www.w3.org/2004/03/04-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: Igor Sedukhin
--------------------------------------------------------
Thursday 4 March
--------------------------------------------------------
08:30 Introductions and logistics
- Assignment of scribes
Igor Sedukhin, Umit Yalcinalp, Youenn Fablet, Kevin Liu
Paul Downey, Jeff Mischkinsky, Asir Vedamuthu, David Orchard
Hugo Haas
Igor, Umit, Youenn, Kevin
- New scribe policy: Since the chair is maintaining the issues list,
but not the edtodo, the two can easily get out of sync. Our
minutes
should henceforth include explicit actions to the editors as well
as
resolutions of issues.
- Agenda review
--------------------------------------------------------
08:40 WSDL Component Designators:
Trolling through old minutes does not reveal clearly whether
WSDL Component Designators should be added back into the draft
as an Appendix. My memory says "yes, we decided that" but the
minutes are unclear and the edtodo does not mention this. If
you clearly remember something different, this is your chance
to scream.
Jonathan: WSDL Component Designators should be added back into the draft
as an Appendix.
[No objection]
ACTION: Editors to add back the WSDL Component Designators back to the
spec as SHOULD.
--------------------------------------------------------
08:43 Correction to minutes on wsdl:ServiceType [2]. Confirm
correction to the minutes as enumerated by Umit.
[2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0224.html
Glen: This was my proposal and this was resolved at the last F2F.
Umit: Checked and this was done.
Sanjiva: Spec is not clear on when service name attribute is required.
Glen will look at that
ACTION: Glen to look at schema derivation in the current draft
--------------------------------------------------------
08:45 Issue 79: How much validation? [3]
Jacek posted a relevant proposal [4].
David's analysis [5]
[3] http://www.w3.org/2002/ws/desc/2/06/issues.html#x79
[4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0121.html
[5] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0234.html
[dbooth: My presentation:
http://www.w3.org/2004/Talks/0304-dbooth-wsdl-lang-vs-proc/]
DB presentation: WSDL Language vs Processor
DBooth: Separate section in the spec on the processor.
Roberto: Then we need to add a WSDL editor too.
DBooth: Yes, maybe. Extract all the statements about what WSDL
processor should do and put them together. Such statements
are already in the spec, but scattered.
Jonathan: Another pro I was expecting is simplification of the spec.
Will address the complexity problem by addressing the
language in the main spec.
Arthur: We can spec the language without necessarily calling on the
processor.
DBooth: WSD is a set of assertions about interacting agents. WSD
only partially describes the interaction.
Umit: You seem to imply that WSDL is not a complete contract. Does
not agree with that.
Glen: That is actually true, it is not complete.
[JacekK: Bijan, does David have the defn of monotony right? 8-)]
Umit: It should be true by looking at the WSDL which must be the
base.
Bijan: The original contract may not be sufficient, but why is it
not complete?
Glen: There could be out of band things that WSDL does not capture.
Sanjiva: WSDL is necessary, but may not be sufficient.
DBooth: WSDL is a contract, but there could be additional obligations
Extensions: extensions are non-monotonic.
Glen: Extension may change the original 'assertion'.
Jacek: That should not be true.
Bijan: It depends on the extension. It defines if it is monotonic or
not.
DBooth: Yes, but we cannot assume.
Jacek: Binding extension only affects the binding.
Glen: Except that if it adds default operations in which case it
also affects other description component
DBooth: (from TAG) extension is ID'ed by a qname, target namespace
must identify the meaning. Proposed clarification text for
6.1.1. Limiting the scope of understanding to the component
to which mandatory extension is applied to.
Arthur: That means existence of such extension may affect the whole
document.
Glen: Like in SOAP, look for those .. addressed to you and then
look for what you must understand.
Bijan: The doc means different things depending on how one processes
it.
Roberto: At least it coerces it.
Kevin: Is the meaning of the whole component affected by a mandatory
extension?
DBooth: Essentially yes
Glen: mustUnderstand = required = mandatory. You don't change the
meaning of what the binding is.
Bijan: You could.
DBooth: Mandatory extension may change some of the assertions
expressed in the WSDL spec
Gudge: Ext mandatory not = it changes the semantics. Do we expect
those things to so fundamentally change what is expressed
in WSDL.
Glen: Yes that is possible and we need to craft this into the spec.
Bijan: What does this mean for validation of the WSDL doc?
Glen: You can't validate what you don't understand.
Bijan: If the meaning of the component is changed its validation
rules may change too.
DBooth: The spec is directed towards the meaning of the WSDL
document.
Glen: Difficult part is to describe the rules for the extension
writers and make sure that does not screw up.
Jeff: If binding ext adds ops why is it changing the interface?
What is being validated: the document or how it is
processed? Turning this into the context-sensitive language.
Have to express what the context is.
Kevin: Agrees with Jeff. If there is a binding and an ext and if I
only need to understand the binding only and not the ext
then why should I care about the ext? With the proposed
changes I will need to.
Roberto: The meaning of the component containing the ext is changed?
What if the component was 'built' before the ext was added?
DBooth: Maybe component is not right word, may be the element.
Jeff: It feels like the 'foundation of sand'
Jacek: .. lost ya...
Gudge: Why is important for service to say the extension is
required?
DaveO: Isn't it that the client just does not want to have the
error msgs? It wants to know up front what is required.
Gudge: Do we anticipate exts that are optional. Are there use cases?
[KevinL: In the "late bound" case, if there are multiple binding
extensions defined under the wsdl:binding component and are
all marked with wsdl:required, for a processor who only care
about one of the binding extension, why should it be failed
if it doesn't understand a binding it doesn't care at all?
Especially in the "late bound" case where the WSDL file is
discovered at run time, and artifacts are generated at run
time to communicate with a service.]
Jonathan: Let DBooth proceed.
DBooth: Optional exts
[pdowney: Trying things out and faulting can reveal your hand - like
playing Cluedo..]
DBooth: Those that do not change the meaning of the WSD assertions.
Glen: That is not necessarily true.
Bijan: It is not monotonicity, it is the "ignorability" that is
doing it here. Being monotonic is not a sufficient
characterization.
Roberto: Then adding implicit ops to the interface by an ext will
not be optional now?
Glen: The ext adds those ops if you want to process it.
[JacekK: <wsdl:binding>
<soap:binding/>
<http:binding/>
...
</wsdl:binding>
is this allowed?]
[Bijan: I.e., optional extensions are optional only for the service
client, not the provider.]
Kevin: Required by who: the consumer or the provider?
Jonathan: WSDL is from the service POV we agreed.
Sanjiva: Move on
[Bijan: It's *not* the case that the server is obligated to support
all that. At least, that's not the right way to put it. It's
a fact of the *language*, that the document won't be *true*
unless the server supports all the extension,etc. etc.]
Glen: Add an issue: is there a difference with client or service
obligation with regards to ext.
[Jonathan: New Issue: What is the scope of extensions?]
DBooth: WSDL defines the way two agents interact and the way to test
it is to actually verify if the interactions are as
described.
Arthur: Test case: WSDL and the message and assert if the message
is conformant to the WSDL. Another one is to give a sequence
of messages and assert that against the WSDL.
Glen: Unless there is an ext that says something about the
semantics of the op.
Arthur: 1) is the WSDL consistent 2) is message conformant 3) is the
sequence of messages conformant.
DBooth: We should be able to test anything that the spec says the
processor should or should not do. Bottom line: separate
the processor from the language.
Jonathan: We can adopt this and close the issue 79.
Tom: Will this make the spec more or less readable? Is Jaceks
proposal on including statements on validation in the spec
also with this issue?
Jacek: Was looking to separate it out.
Glen: Also wants to keep it separate.
DBooth: There are simple questions 1) separation of the definition
of the language and assertions about the processor.
Glen: Cares that we have clear expression of that whether or not
it is in a separate section.
DBooth: Can modify the doc and generate the changes that the WG can
look at.
Jonathan: Is this simply an editorial issue?
[Bijan: +1 to cleaning specifying the *semantics* from various bits
about arbitrary processors but not moving text around :)]
Tom: Just state what has to be validated and add this text
anywhere in the spec.
[Bijan: I.e., for each section, you can just add a "Note: A
processor that blahblahblah would blahblah blah with this
component"]
Hugo: There is no impact of what DBooth is proposing on the WG
schedule.
Glen: Let DB do it or reject.
Tom: Does making these editorial changes address issue 79?
Jonathan: Yes.
Umit: Will the statements include "conformant processor"?
[GlenD: as opposed to say "buggy processor"... All buggy processors
MUST put $500 into Jacek's bank account.]
Sanjiva: That would require defining classes of processor, there
should be one for clarity.
Jeff: There has to be the definition of what processor is meant.
Start with those things that matter for interop.
[.. snip ..]
Jonathan: Just define the meaning of the language :)
Bijan: Can't entirely *ignore* processing issues when specifying
the semantics& different semantics can make processing
sane or not.
Sanjiva: Needs clarification 1) scope of required and that is it.
Arthur: We are transplanting SOAP approach to WSDL. SOAP has
processing model and WSDl doesnt. Define how processor
maps infoset to the component model and that defines
conformant processor.
Gudge: How is that different from the way the spec is now?
[DaveO: Glen, btw my point about "optional" bindings is that you
and I might use the same WSDL, but I implement one binding
and you don't. That to me should be ok. If we are both
"required", then I should have to.]
Glen: The issue of "requiredness" is different from separating
the processor assertions.
[GlenD: If we both claim to implement the same WSDL, we both need
to be prepared to accept anything which is produced by
clients which process that WSDL. So with bindings, you're
right, in that it's unlikely I'm going to implement a WSDL
that actually has your endpoint address in it.]
[DaveO: If they only use required. The whole point of "optional"
is that it isn't necessary. :-)]
[GlenD: But if I put an optional extension in an interface which
allows two different behaviors, ANY implementation of that
interface must accept both. That's my point.]
[Bijan: Hmm. Glen, with features and properties, one can, in some
sense, avoid the global scope of extension changes in this
way. Extensions can always set properties. So a binding
could set a property. And in the interface, I have a
feature parameterized by that property. Which say, adds
an operation (or "enables" an operation).]
[DaveO: Glen, I disagree. If there are 2 different behaviors that
must be accepted, then they should be required, not
optional.]
[GlenD: DaveO: the whole POINT of the optionality is that the
client can do EITHER.]
Sanjiva: "Processor must do x" is ok to use except the extensions
part.
DBooth: Should we continue to mix definition of the language and
processor assertions?
Sanjiva: Yes, that is ok.
[GlenD: And if the client can do one of two behaviors (avec ou
sans extension), any implementation which claims to be
conformant must accept both.]
Gudge: Are there places where the processor is implied, but not
asserted?
DBooth: Not sure about that.
Sanjiva: Right now the processor comes up only in types and
extensions. Let's just fix the exts section. Processor
assertions in the types section are ok right now.
DBooth: This does not clarify the requirements on the conformant
processor though.
[GlenD: This discussion has instilled in me a deep and sincere,
and in no way optional, desire for caffeine.]
Sanjiva: No-one has complained about it so far, but there are a lot
of complaints about the exts section.
[Gudge: Gudge concurs with glen]
[JacekK: Do we keep discussing it or do we just trust the editors,
since we're not yet really going to LC?]
Jonathan: However we can have a section on conformant processors that
has all the necessary assertions. Introduce the conformant
processor section and solve the two outstanding issues.
--------------------------------------------------------
11:00 Break
--------------------------------------------------------
11:30 Issue 79 continued.
Current proposal, add conformance section with:
1) document conformance: conform to schema, etc.
2) infoset conformance
3) processor conformance (types, exts, Jacek's proposal)
Sanjiva: 3 builds on 1 and 2.
DBooth: Add to 3) accepts any conformant WSD.
Jonathan: Proposed to the group to accept this
Group did not disagree
RESOLVED: Add conformance section as above.
[DBooth: PROPOSAL ACCEPTED! WE HAVE PROGRESS! HALLELUJAH!]
ACTION: Editors to incorporate the above proposal.
ACTION: DBooth to propose specific changes needed for
processor conformance text]
[Issue 92, Issue 133 skipped for now.]
--------------------------------------------------------
10:50 Issue 112: Headers at the abstract level [9]
- Headers as first-class citizens [10]
- Glen's OOB feature proposal [11]
[9] http://www.w3.org/2002/ws/desc/2/06/issues.html#x112
[10] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0004.html
[11] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0053.html
DaveO: Headers are fundamental at the protocol level. Most protocols
have headers.
Glen: Two mechanisms now: F&P and the binding. F&P may attribute
what data needs to go into the application and then binding
could lay it out into the header.
Jonathan: There may not be disagreement that we do it via F&P.
Umit: The proposal is that F&P is used, but there is an additional
1st class construct
Jonathan: There was agreement that we will add such a feature. Close
with AI on Glen and Yaron to reconcile?
DaveO: We're not near the consensus there.
Glen: It is simply side band data, why constrain it at the abstract
level?
DaveO: Having it at the abstract level may help apps to decide
where to look for such information. We should take
advantage of the SOAP model.
Glen: It is not good to encourage people to say something must be
in the header or not.
Sanjiva: Can the same feature be used in the component?
Jonathan: Same feature URI can be used repeatedly, yes.
Glen: F(P*) not necessarily (FP)*. My proposal has one header
(composed of various data)
Sanjiva: We agreed on F&P mechanism for defining headers on the wire.
Glen: We still wanted to have a header and not multiple.
Roberto: If the feature components are different that may be multiple.
Sanjiva: These proposals have to converge.
Glen/DaveO: That's the problem.
Jonathan: Clarification: application headers vs protocols headers.
Tom: Defining headers is what people do with WSDL.
Sanjiva: HTTP has mechanism for both sorts of headers. WSA defines
headers for SOAP.
[Yves: Point of clarification, cookies are NOT in rfc2616
(HTTP/1.1 spec), so there are not 2 ways of doing
extensions in the spec.]
DaveO: We're building toolkit that allows both kinds of headers.
Tom: It should be possible to mix headers and it should not be
constrained by WSDL.
DaveO: To get to consensus: we want a generalized facility and
then the other well defined ones.
Glen: It does not work that way, 1) there are the headers or
2) here is the data that appears in the headers
[Will attempt to reconcile positions during lunch.]
--------------------------------------------------------
12:15 Lunch
Scribe: Umit
--------------------------------------------------------
12:40 Issue 112 cont.
[GlenD: <soap:Header>
<myDangerousStuffMasqueradingAsApplicationData
soap:mustUnderstand="true"/>
</soap:Header>]
Jonathan welcomes the schema group members as observers.
Issue 112: Glen suggests that it should be closed with a future proposal
Glen suggests a strawpoll:
1. one bag one header for an application header
2. There can be multiple headers for applications.
3. abstain
Paul: Is this about SOAP binding or WSDL in general?
Glen: We can resolve this by defining one single feature.
Jonathan: We can solve this by one feature, but we don't have to
solve whether this resolves into one or more headers right
now.
[Anish: Does proposal one prevent proposal two and vice versa, or
is it a question of what we want to encourage?]
Glen: We will define how it gets resolved in the future for SOAP
binding.
DavidO: Objects because it makes Glen's proposal accepted.
Correction: Third option is to do nothing, not abstain.
DavidO: The question is whether there is one place to put app data
or be flexible as BEA proposes.
Sanjiva: We should close the issue, continue to work on the action
item for Glen. We are not done yet with respect to the
action item since there are two proposals.
RESOLUTION: Close this issue. Open another one to decide whether there
should be a single header vs multiple headers (or both).
--------------------------------------------------------
14:00 Issue 109: WSDL versioning [12]
- Use cases (DavidO) [13]
- Requirements (PaulD) [14]
- Scenarios
[***** ACTION: DaveO to write up a proposal for augmenting
schema information to enable versioned data. *****]
[12] http://www.w3.org/2002/ws/desc/2/06/issues.html#x109
[13] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0016.html
[14] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0082.html
PaulD: Must understand with tag finding should be discussed.
[DaveO: My post to schema is at
http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0124.html]
PaulD: If we have WSDLs with versions, the next thing that needs to
be discussed how do we refer to them?
DavidO: There are multiple things that are in WSDL that the Schema
group do not care about, but issues about what we do with
Schema is relevant to the schema group. Adding operations,
etc should be addressed separately.
Jonathan: The issue is what do we do with documents that have the same
namespace.
DavidO: We use XML schema to describe the messages. Is there a
different interpretation of Schema we can use? Is there a
dial in the schema that we can use that allows the
extensibility desired?
PaulB: If you use a restricted schema, this is possible. If content
model is flat and the extra content is at the end, it is
deterministic and easy to accept a document. There are two
attributes: Validation attempted and validity.
[HenryT: Their relation is discussed in detail in the following
informal
note, which WSD WG members may find helpful:
http://www.w3.org/XML/Group/2001/06/validity-outcomes]
[asir: http://www.w3.org/XML/2001/06/validity-outcomes.html is the
public version]
PaulB: If the root node is invalid, you can look down the tree and
strip the nodes that are valid unknown.
CMSMCQ: Paul's algorithm is applicable with Schema 1.0 with the
restrictions that are defined.
Jonathan: There may be a convention we can recommend in WSDL. Is this
true?
[DaveO: There's a really cool benefit, you don't need wildcards..]
HenryT: Use global elements and validate twice. Use 1st time what
Paul recommends, and validate again.
Sanjiva: Why are we talking about this? This is not about WSDL.
Jonathan: Versioning of schemas is relevant for us.
Sanjiva: Perhaps a note from the schema group
DavidO: If we want to enable someone to take advantage of the
double validation, etc. we need to say explicitly say it
in WSDL.
Jonathan: Use a style.
JeffM: We can be more prescriptive about the way the Schema is used.
[DaveO: Q: does this require special schema tools]
Paul: The result of a schema processor should make more
information available but it is doable by the current
processors
CMSMCQ: Use top level elements. Use what you learn with regular
languages. The techniques may be recommended for schema
authors.
HenryT: WSDL should recommend WSDL normalized schemas. With
wildcards added at the end.
Jonathan: If this is solved in Schema 1.1, we can recommend moving
to Schema 1.1
HenryT: We can recommend best practice.
[HenryT: The advantage of the two-pass story doesn't require authors
to take action.]
DavidO: Two pass processing does not require the WSDL author to
include a wild card.
[HenryT: Paul Biron points out that receivers are in control in e.g.
the two-pass+surgery story. Whereas in the
auto-insert-wildcard(+boundary) story, the receiver has
lost control of how strict they want to be.]
PBiron: Is the extra stuff in the same namespace or not? What are
the requirements for the extra stuff?
DavidO: If there are constraints, that may allow us to get to the
point needed.
Sanjiva: This is not problem for WSDL.
[HenryT: So I understand MSM's suggestion as saying -- "Give me a
schema for a WSDL language -- I'll use redefine by extension
to make every type, or any subset of types you name,
extensible, by redefining by extension with the above]
Sanjiva: The schema is not defined by WSDL, it comes from somewhere
else.
[HenryT: Note this rules out schemas which use 'all' groups (no bad
thing :-)]
DavidO: If there is a mode, WSDL 2.0 can define a WSDL application
of schema with the validation rules that are discussed.
DavidEzell <scribe misses some points>.
DavidO: We have extensibility and versioning. It is not clear how
they overlap. There are instances when versioning and
extensibility collide. It is very hard to decide where
the boundaries of versioning are.
DavidEzell: You need to give a hint up front when you have a new
version up front, with a new namespace.
JeffM: We have not decided what we mean by versioning.
Asir: Says that the WSDL does not care about the underlying type
system, why are we discussing schema specific issues?
Jonathan: We need to specify at least Schema for interop.
Bijan: Can we take this out of critical path for Part 1 to meet
our timeline?
Jonathan: If we can adopt a marker and best practices, it would help
the problem.
DavidO: I will get my customers to send a last call comment if this
is not handled here.
[Bijan: Ah, that was what I wanted :)]
DavidO: we are describing the validity of the message, this is part
of the description.
JeffM: You have not established what the requirements are. Get a
definition of versioning first to move on.
PaulD: We are not only using schema, this is intrinsic to WSDL.
We generate messages as well.
DavidO: If it is done with the primer, the functionality will not
be in. Put this on the back burner as an issue. If we can
close all the other issues, we can come back to this.
Bijan: Q for David. Lets say have a task force and come up with
recommendations? Should they be normative?
DavidO: Yes. There are range of solutions
Bijan: If we need to solve this problem, this will affect Part1.
DBooth: This is a best practices issue. This can not be normative.
Sanjiva: Close this issue right now. We already restrict the
messages with XML rules. If there is additional
constraints within the schema expressed by schema, it
will be perfectly fine. This is a solution offered by
schema.
Jonathan: We need a definite proposal.
DavidO: Why aren't the people in this group interested in pursuing
with this with Schema wg?
JacekK: I am interested in pursuing WSDL construct versioning.
Lets move this issue to the primer.
[KevinL: +1 to move on. I don't believe we agreed to move data
versioning to primer.]
[Discussion on whether we should have a joint task force goes on. ]
Jonathan: The mission of the task force is to come up with improvements
to Part1 and Part2 or Schema itself?
[sanjiva: I have completed the action item to insert a conformance
section - would appreciate if DavidB and others would take
a look and propose additional conformance constraints.]
RESOLUTION: Joint tf with Schema and WSDL to investigate whether
there may be mechanisms developed.
RESOLUTION: Close the issue.
ACTION: Primer to include best practices and the Schema group to
review the best practices language.
--------------------------------------------------------
15:10 Issue 140: Version attribute [15]
- Tom's initial proposal [16] and follow-on proposal [17]
[***** Paul to develop clear enumeration of options *****]
[15] http://www.w3.org/2002/ws/desc/2/06/issues.html#x136
[16] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0049.html
[17] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0069.html
[pdowney: Has posted an attempt to synthesize the versioning discussion:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0014.html]
CMSMCQ: My perception is that there is a need to point to the version
of the schema language.
KevinL: Three issues: attribute for defn, define how to use it,
version attribute for interface.
PaulD: If there are two documents with the same namespace, how do
you differentiate? You need to know which is the newer
version.
Gudge: The usage of namespace is the same as in schema.
DavidO: The reason for a version attribute is to allow compatible
changes to be introduced without changing a namespace.
Changing a namespace is costly for introducing compatible
changes. We also need to construct a uri from the version
attribute in addition.
[pdowney: So is the definitions namespace synonymous with the
interface major version ?]
Sanjiva: We need to make changes to all our components in order to
refer to versions of the components. This is drastic change.
[Anish: +1 to Sanjiva's comment]
Sanjiva: Versioning of the definition is not meaningful.
[GlenD: Wow. Sanjiva rocks my world.]
JacekK: Version attribute does not help much except when WSDL is
downloaded and you need to refresh/regenerate artifacts.
[DaveO: +1 to JacekK's pov]
JacekK: We don't need to say more than that.
[JacekK: dbooth, personally, I think checksum or diff is simple
enough, but I guess for some people this might vary.]
KevinL: Optional version attribute will be helpful in the defn
elements will be helpful for internal development.
GlenD: When definitions have to refer to other documents, the
referencing will be problematic. You need to carry the
version attribute to make sense of what is being
referenced. There is not much need for this, other than
the use case JacekK brought up.
WilliamV: we should not do anything on this, but if we do we should
use the namespace URI to convey version info.
[TomJ: I think messing with the target namesapce and adding a
version convention is not a good idea]
[sanjiva: +1 to it not being a good idea]
Bijan: There are two aspects to the problem: when to say things
are different and how to define relationships between
things.
JeffM: This problem is an old problem. The version attribute with
unspecified semantics is not useful. We need to define
substitutability.
DavidO: Schema group has looked into the formal defn of
substitutability, acceptable sets, etc.
[pdowney: wanted to state that David and Norm's TAG finding on
versioning matches his practical experience]
Igor: Version is useful at runtime. If one needs to maintain
relationship between changes, change management is the
place to do it.
[pdowney: Interesting point from Igor - that actual version could be
discovered at runtime.]
Tom: Describes the details of his proposal. Version attribute
indicates a minor revision.
[MSM: For the record, the current rough draft of the schema paper
on accept sets, etc. is at http://www.w3.org/XML/2004/02/xsdv]
Tom: If WSDL artifacts change, the compatible changes are adding
operations, added endpoints. These changes allow the
clients with the old versions to still operate. This solves
a very well defined set of problems. This is not a solution
to the entire versioning problem.
[DaveO: big + 1 to Tom.]
[KevinL: +2]
[igors: Tom, if someone has changed the wsdl or schema then he has
to change the namespace. Things won't work otherwise.]
[Roberto: A hash computed by the consumer of the wsdl would work just
as well as the version attribute (actually better, because
the client could decide what the relevant information is)]
[DaveO: Tom, don't do that.]
RESOLUTION: Close the issue with no action.
--------------------------------------------------------
15:45 Break
--------------------------------------------------------
16:30 Joint Session with TAG (Web arch [21])
- Saying more about QName mapping (?) [22]
- Error recovery vs. not having to "validate" parts of the doc not
used or examined by a processor. [23]
- Comparison of XML namespaces with Schema and WSDL namespaces. [23]
- Cracking a component designator URI. [23]
- Operation safety? (Issue 117) [24]
[21] http://www.w3.org/TR/2003/WD-webarch-20031209/
[22] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0164.html
[23] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0180.html
[24] http://www.w3.org/2002/ws/desc/2/06/issues.html#x117
[dbooth: Jacek's WebArch comment from
http://lists.w3.org/Archives/Public/public-webarch-comments/2004Feb/0030
.html:
4.5.5 below the Good Practice: QName Mapping - the section
(or some other) should probably say more on the
interaction of QName Mapping, fragment identifiers in XML
(4.5.8) commonly used for this mapping and namespace
documents (4.5.4)]
JacekK: We need a new scenerio to connect sections.
[dbooth: WebArch section on QNames:
http://www.w3.org/TR/2003/WD-webarch-20031209/#qname-uri-syntax]
[plh-lap: (sections 4.5.5, 4.5.8, 4.5.4)]
Stewart: If Qnames are going to be used for identification, you need
a mapping to URI space.
JacekK: However, there is no requirement to use these mapped URIs
somewhere.
[Chris:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0180.html]
DanC: The discussion is still going on, there is an error
(number?) and the architecture document just reflects
the current state.
Next issue:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0180.html
DanC: Should be clarified if not clear enough.
[Gudge:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0180.html]
Jonathan: We name abstract components in a targetnamepace. We have
taken the namespace to a different level.
DanC: How does the qnames and targetnamespace interact? Have you
specified how Qnames mapped to URIs? If you have done this,
you are done.
Jonathan: Do we need the mapping for URIs for the importing mechanisms
in WSDL? It is ambiguous whether the namespace should be
absolutized before adding to the component model.
[Gudge: Likes the notion of mandating that targetNamespace URIs be
absolute to begin with.]
[DaveO: +1 to absolute URIs. ]
[asir: +1 to absolute URIs. Simple things should be simple.]
umit: +1 to absolute URIs
[dbooth: +1 to absolute URIs]
[jjm: +1 to URIs, absolutely]
[Chris: +1 to absolute URIs fwiw]
[Anish: +1 to absolute absolutely :-)]
[alewis: +1 to absolute URIs in targetNamespace]
DanC: Don't canonicalize, just absolutize then compare string by
string.
Jonathan: There needs to be one mechanism for interop.
[Stuart: URI comparison bit in RFC2396bis is at
http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#comparison]
ChrisL: Agrees with DanC (if scribe got it right)
[asir: My +1 was to mandating that targetNamespace URIs be
absolute to begin with]
[Chris: Mostly - except dan expressed that comparing IRIs either by
character or by hex escape was undecided whereas actually
the IRI spec says to compare them by character]
Jonathan: Is the relative URI allowed for schema [namespaces] imports?
[Stuart: Basic idea is that there are multiple comparison functions.
There is one 'identity' function (absolute and then compare
character-by-character). Other compariisons must respect
'identity'.]
[DaveO: rfc 2616 says http://www.abc.com and http://www.ABC.com are
the same.]
[Chris: Yes, and http says that foo.org and foo.org:80 are the
same.]
[DaveO: yup.]
MSM: If it is not an absolute, it will not work.
[Stuart: ie. beyond an identity comparison, other comparisons that
compare 'identical' URIs must not say they are different
(I think).]
MSM: Schema does not prescribe behaviour for absolutization.
DBooth: QName is ambiguous by itself. The mapping should be
sensitive to partitioning.
Stuart: You need to incorporate partitioning.
Component Designator URIs:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0180.html
[Chris: you don't have to use http. But a transport that reports
the media type is easier, naturally. So (to summarize)
webarch says that the interpretation of a fragid depends
on the media type of the resource representation. if you
don't fetch one, you don't know which set of rules to apply.]
[Bijan: (except if you have that information from some other means)]
Issue 117: Operation safety
[dbooth: Hugo's message:
http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0246.html]
[DanC_jam: idempotent(P) iff forAll X P(X) == P(P(X)).
# the definition I carry around in my head]
[Bijan: http://en.wikipedia.org/wiki/Idempotent. Yep.]
[dbooth: Hugo's slides: http://www.w3.org/2004/Talks/0304-hh-wsdl/]
[Bijan: Which isn't what Hugo said. Or, at least not clearly.]
hugo: Idempotent messages get the same result regardless of the
number of times they are repeated.
[Roberto: The bit about side effects for idempotent operations was
suspect.]
[Bijan: "same side effect" must mean *the* very same *one*.]
[caribou: http://www.w3.org/TR/2003/WD-ws-gloss-20030808/#idempotent]
[Roberto: right, just one in number]
DanC: Motivation for safe is important. The lower levels need to
know whether the operation is safe or not defined by the
person that defines it.
[Stuart: There is clearly more to be said about idempotency - see
http://www.amazon.com/exec/obidos/tg/detail/-/052155344X/qid=1078416611/
/ref=sr_8_xs_ap_i1_xgl14/104-6324547-4209537?v=glance&s=books&n=507846
:-)]
Bijan: Is this the only place where we define something about
semantics of an operation/Message exchange?
Discussion ensues whether GET operation is safe or not.
[Stuart: Idempotency and Safety enter the vocabulary from RFC 2616
Section 9.1 (HTTP 1.1 spec)
http://www.faqs.org/rfcs/rfc2616.html]
Bijan: Safety is context dependent.
Sanjiva: From WSDL perspective, the question is whether we should do
the marking of safeness at the abstract level or not.
[Stuart: BTW defn of idempotency n RFC 2616 is not very adequate
either (side-effect free)]
Arthur: Most of the Web is for information retrieval. It is a good
idea to mark safety at the abstract level.
Glen: Is it possible to break the safeness in different levels in
WSDL by adding additional headers, etc?
JacekK: It's not yet clear if an operation identifies a piece of
functionality or not, because if not, we cannot mark an
operation as safe as that depends on the functionality
behind the operation.]
[Chris: Yeah, it has the same result every time ....]
Stuart: There is no way to make the WSDL generator to define an
operation to be safe for bottom up case.
[DanC_jam: Yeah... what he's saying.]
[Chris: Modula-3 allows modules to be marked as 'unsafe' meaning
they use untyped memory access.]
Arthur: For top down, it is relevant to be able to mark operations
as safe.
[pdowney: +1 to Arthur]
[DanC_jam: I heard Arthur mention several programming languages with
a relevant notion of safeness: const in C++, .Net attributes,
Java 1.5 something.]
KevinL: What is the safeness mean for the client of the service?
Why is this useful?
[asir: according to Hugo, e-mail, - a safe operation is cacheable;
it may be serializable as an HTTP GET (or even HEAD) request;
if so, the request can take advantage of the Web
infrastructure such as caches. A toolkit could make the
choice of using an HTTP GET or SOAP GET binding for such
operations (e.g. GetStockQuote) if there where marked as
such. Knowing that an operation is safe or idempotent
can allow poor-man's message reliability, or message
reliability optimizations: safe and idempotent operations
can be repeated without additional side-effects, and
therefore this eliminates the problem of ensuring that a
message is received only once.]
[Chris: http://en.wikipedia.org/wiki/Idempotent]
Jonathan: An example is when your credit card is going to be charged
and you are informed on the web.
[Chris: In user interface design, a button can be called
"idempotent" if pressing it more than once will have the
same effect as pressing it once. For example, a "Pause"
button is not idempotent if it toggles the paused state.
On the other hand, if pressing it multiple times keeps
the system paused and pressing "Play" resumes, then
"Pause" is idempotent. This is useful in interfaces such
as infrared remote controls and touch screens where the
user may not be sure of havin...]
[plh-lap:
http://www.w3.org/TR/2003/WD-webarch-20031209/#safe-interaction]
DanC: Web Architecture has already defined.
SAnjiva: It is not covered for all the MEPs that exist in WSDL. We
have to define it for any pattern.
[Stuart: FWIW see RFC 2616 "9.1.1 Safe Methods"]
[Arthur: I said that Java 1.5 will have code attributes, so even
though there is no language syntax to mark a method as
safe, you could define a code attribute to mark a method
as safe. In C++ you can mark a method as const which means
it doesn't modify the object.]
[Roberto: minor nitpick: they are called "program annotations", or
simply "annotations"]
Chris: Safe does not mean that anything bad will not happen, for
example downloading illegal material from the web may be a
safe operation.
[Chris: because no additional obligations were incurred]
[Arthur: In .NET there are code attributes and these are used for
Web services, so you could also define a new .NET code
attribute to mark a method as safe.]
PaulD: Worries that 'safe' is just one instance of a generic
problem - how to publish policy.
DBooth: We need to clarify that the safety is from the perspective
of the client for any MEP.
DAnC: The only requirement that I can speak for is the
Request/Response (In-out) pattern
[plh-lap:
http://www.w3.org/TR/2003/WD-webarch-20031209/#safe-interaction]
Phillipe: Section 3.5 of the Web Arch docuement will suffice
[DanC_jam: (I don't know whether "input messages" get exposed
sufficiently to designers)]
Jonathan: Lets refer to HTTP or web architecture document.
[dbooth: DanC, yes in WSDL they do get exposed to the designer to
the same degree as operations.]
Glen: Has an issue for addressing interactions with extensions.
JacekK: Do we expect/agree when we have an operation in an
interface that we can assign semantic to an operation?
This is the same problem, because assigning safeness is
adding semantics.
--------------------------------------------------------
[Chair recalls Joint session TAG ended at about this point.]
[Discussion onto whether the operation carries semantic or not.]
Gudge: What are we looking for? To label an operation "safe" in
the same way the HTTP GET is safe?
Sanjiva: This may not work in general, but we are asked just to add a
mechanism to enable marking safeness.
[TomJ: If we have to add it because the tag will demand it, lets
just stick some syntax in there and we can be done with it.]
[KevinL: +1, but that syntax must be optional]
[plh-lap: 1. safe='yes'
2. safe='http://..../safe'
3a. feature/properties (we define the uris)
3b. feature (we define the uri) / property (we reuse
soap/get)]
[sanjiva: +1 for (1)]
The wg starts discussing whether the safeness should be expressed via
feature (hugo), a simple property (Tom), feature at the abstract
level (and property at the binding), etc.
[anish: +1 to feature -> webMethod]
Proposal: Add an attribute on operation, default to false to indicate
the safeness.
[KevinL: against default to false. If not specified, it means no
claim is made.]
[asir: SOAP 1.2 - Underlying protocols designed for use on the
World Wide Web provide for manipulation of resources using
a small set of Web methods such as GET, PUT, POST, and
DELETE. These methods are formally defined in the HTTP
specification [RFC 2616], but other underlying protocols
might also support them. Bindings to HTTP or such other
protocols SHOULD use the SOAP Web Method feature to give
applications control over the Web methods to be used when
sending a S...]
Glen: This is the same as setting the webMethod to GET.
[plh-lap: -1 to reuse the webMethod get property]
Jonathan: We will have duplicate information if we need to specify
the web method in the binding as well as the abstract level.
Sanjiva: Proposal: Add a safety property to the interface operation
component.
[plh-lap: Property?]
[anish: Is the WSDL then going specify exactly what is meant by
"safe"?]
[plh-lap: We point to the web architecture]
Roberto: Property syntax is better because it can mark interfaces to
be safe instead of defining it on operation.
[plh-lap: And if people don't like the definition of safe in web
architecture, they should fix the web architecture.]
Glen: There is no reason to add anything to the component model.
The wg continues to discuss properties in component model vs features
& properties.
[Arthur: e.g. ASP.NET happily exposes every operation of a Web
service as SOAP/HTTP, HTTP GET and HTTP POST]
Straw Poll:
1. boolean property to operation component
2. use property (from F&P) to designate safety.
7 in favor of 1
8 in favor of 2
Resolution: We don't have a strong preference.
Bijan: redo the strawpoll.
Boolean property in favor 8
F&P : 8
[Chair asks who cannot live with the approaches, there are some on
each side. Chair adjourns meeting, will figure out a procedure for
moving forward before tomorrow.]
[hugo: Hugo's slides: http://www.w3.org/2004/Talks/0304-hh-wsdl/]
[Issues 123, 117, @wsdlLocation skipped for now.]
Received on Tuesday, 9 March 2004 11:41:06 UTC