Notes from the OASIS
WSRF TC teleconference
24th January 2005
Roll call
The roll call is kept on the TC web site
under the meeting record.
See http://www.oasis-open.org/apps/org/workgroup/wsrf/event.php?event_id=4812
Approval of minutes from the previous teleconference call (10th
January)
See http://www.oasis-open.org/committees/download.php/10950
There were no comments on the minutes and no objections to
approving them.
Call for AOB
(DaveS) Do we need to discuss the ‘reference properties’
issue of WS Addressing? Did anybody attend that meeting?
(Tom Rut) I was there.
(Mark Peel) Me too.
(DaveS) Ok – we’ll do that before the main issue review.
Action Review - Dave
(MartinC): Write a clarification of the requirement for issue 64. (Post Schema
Validation) (Carried fwd from 29th Nov.) In progress, carry until Face-to-face.
(Bryan) Move issues WSRF 86, 87, 88 to open. Done.
(Interop Testers) Confirm implementations, outlook for availability &
contact names via mail list. Carry fwd until next call.
(Bryan) Move issue 66 to ‘deferred’, issue 68 to ‘resolved’. Done
(Charis) Carry forward discussion of issues WSRF72, 64, 79.
New
Issues - Bryan
See http://www.oasis-open.org/apps/org/workgroup/wsrf/download.php/11117/WSRF_IssuesList.doc
WSRF89: BaseFault originator field
(DaveS) it sounds like something that we should debate.
No objections.
Action: (Bryan) Move to open.
7. Progress on interop document - Tim
8. XTech Conference
See: http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200501/msg00039.html
(DaveS) People should follow up by the next call with Dave
if there is any interest.
Action: (DaveS) reply to the
Agenda prep for F2F.
(KatyW) Can we discuss Appnotes?
(DaveS) Yes,.
Action (DaveS) Add this to the agenda.
Effects of the ‘Reference Properties’ decision in WS-Addressing
(TomR) After a lot of discussion, reference properties were
removed, but reference parameters were kept. These are put in the EPR and are
echoed back to the server. I asked about using the ref parms, and there is
nothing to prevent their use as identifiers. So, we could use ref parms whose
semantics are defined by WSRF, not by WS-Addressing.
(IanR) That’s the same message we got via IBM.
(MarkP) Yes, that’s right.
(Unit) It’s not clear that parameter is what we should use.
The spec doesn’t say what should be done with them.
(TomR) The ‘identity’ word has been completely removed from
the spec.
(Unit) What is interesting is the comparison definition.
(TomR) Ref Parms are not in the comparison
definition. [2.4 Endpoint Reference Comparison]. That would be part of the WSRF spec.
(Fred?) Wasn’t it the case that the reference properties were
absorbed into the uri?
(DaveS) Anyway, we should add a new Issue
(IanR) Shouldn’t we wait until there’s a new editors draft
of WS-A?
(MartinC) Isn’t this just another embodiment?
(Umit) Yes.
(SteveG) I think the major impact is in the non-normative
examples. Everything else is encapsulated in the WS-Resource spec.
(TomR) The current version of WS-Addressing talks about
reference parameters as the identification mechanism.
(DaveS) Ok, so do we need a new issue?
(IanR) If the WS-addressing draft is out before next week,
we could have a discussion. Otherwise we would have only a speculative
discussion.
(Umit) We still can raise an issue.
Action: (Bryan) Raise an issue, for discussion when
the wsa editors draft comes out, highlighting the ‘comparison’ text for
attention.
(Bryan) Should we have a separate issue to modify the text
of the specs (examples and so on)?
(DaveS) Yes.
Review of Issues priorities document – Ian
This is posted to the list now. This new list is the order
in which we tackle issues at the face-to-face meeting to get the first specs
stabilized.
(DaveS) Shouldn’t the model-level issues be high priority,
too?
(IanR) Yes.
Action: (Ian) Update the priorities list.
Other Issues
WSRF64: Post Server Validation Infoset (PSVI) - Pending input from Martin.
Carry fwd pending clarification from MartinC.
WSRF72: Add operation: PutResourcePropertiesDocument
(Igor) Most of the disagreement here is on the semantics for
the put, and what this does to the RP document, and what information is sent in
the request, and what are the reconciliation rules. The RP document itself can
have properties which are mandatory and provided by the service itself. How
would the service respond if these properties were supplied by the request?
Non-determinism may occur, and is worrisome to some. It is somewhat religious,
and we need to provide flexibility.
(DaveS) So, the questions are the semantics, and whether we
want this at all. The response that comes back is also an issue. My feeling is
that PutResourceProperties document is a rat’s nest. Is there a use case to
guide us?
(Igor) Yes. Suppose we have a customer record that needs to
be replaced? It could be sent wholesale as one would do on the web. We don’t
want to get into the business of individual properties.
(IanR) The problem comes when the properties document can’t
be ‘put’.
(Igor) We can’t tie down what happens to the information. We
can only tie down the message exchange.
(steveG) What is that’s known to both parties?
(Igor). The service sends ‘Success’ or ‘Fault’. Fault can
happen any time. If ‘Success’, then the service includes ‘Document is as
supplied in the request’ or ‘Update was processed, but this is the new version
of the document’. The implementation can decide what happens, as it can always
to: the message exchange does not affect this.
(SteveG) There a lot of client code needed to understand
what happened.
(Igor) It’s the same as sending multiple inserts which have
side effects. The client may need to retrieve the whole document to discover
what happened.
(IanR) In the case of set/update, the response is always a
fault if the request fails.
(Igor) That’s not the issue. It’s what happens when the
request succeeds – there may be side effects besides changing the property
explicitly included in the request.
(DaveS) Yes, that’s right in respect of update. What about
read-only values?
(SteveG) Almost all documents will be read-only in some
respects. How do we know what the client intended – update to X or leave as it
is (whatever that is)?
(IanR) The fault can only be ‘nothing was done’.
(DaveS) SetResourceProperty describes what has and hasn’t
changed. We could be more vague about Set and therefore be consistent in style.
(Igor) I can go with that. WE can so semantics later, but
success will indicate the RP document is exactly as in the request.
(TomM) Perhaps we should say ‘Equivalent’ – meaning that it’s
canonical form is the same.
(DaveS) So the semantics are ‘it all worked’ or ‘it broke’,
and can be consistent with set?
Any Objections?
(TomM) I don’t object to the Put, but the fault needs to
explain what went wrong.
(DaveS) Set returns the part that didn’t work
(Igor) So this is part of it.
Action (Igor): To write up the proposal based on this
discussion.
WSRF79: portType composition and properties document
composition
(Igor) We shouldn’t be telling people how to construct the RP
document.
(TimB) Isn’t that a different issue? Number 88?
(Igor) Ok, It’s about Section 4.4 of the ResourceProperties
spec and how to do composition: this shouldn’t be normative text.
(IanR) Should we simply use this section as a section in AppNotes?
(Igor) We would also need to remove text that references
this section.
(SteveG) Yes, there are some sections and detailed text.
(DaveS) Are there any objections to moving the text?
(TomM) Is it all of 4.4, or the fact that we say that the
GED has to be copied. Couldn’t we just loosen things up instead of obliterating
it?
(SteveG) We could just say use and GED, and whatever else
you need, but if there is merging of portTypes there are difficulties in the
future (for the services which are extensions). The tradeoff is freedom vs extensibility
in the future. Currently the choice is to restrict the form in order to enable
extensibility.
(Igor) So if we go for extensibility, can we describe all of
the valid techniques?
(SteveG) That is what we have now.
(Igor) But mixing can be done with model groups and model
extensibility.
(SteveG) Many tools don’t deal with model groups, and type
extensibility is single inheritance.
(Igor) but WSDL 2.0 is single inheritance.
(SteveG) Maybe for services, but portTypes have multiple
inheritance.
(Igor) Even so, single inheritance is still a useful thing.
(SteveG) So, where do we weight WSRF? Freedom or future
extensibility?
(DaveS) We could put all of this in the AppNotes. If someone
doesn’t read it, the services won’t be extensible – that sounds like a profile/best
practice rather than a spec issue. And this will change in WSDL 2.0.
(SteveG) Well, in WSDL 2.0 we need to reason about portType
extension and what this means for ResourceProperties.
(DaveS) So we should rip it out.
(SteveG) …and there will be some RP docs that don’t migrate
forwards.
(DaveS) So this should be in the spec? Where do we go:
perhaps a straw poll at the face-to-face?
(MartinC) We just need a motion.
(Igor) I think it needs more discussion.
(DaveS) We need to discuss this at the face-to-face.
(IanR) I think we should combine issue 79 and 88.
(TomM) Seconded.
Action: (Bryan) Combine the issues into one.
(IanR) We should discuss this further: we need to refine the
text or move it out into AppNotes.
Action: (Chairs) Continue discussion of issue 79/88
at the face-to-face.
(DaveS) Any more burning issues, like logistics for the face
to face?
Meeting closed 13:26 est. Next meeting is the face-to-face
on 2nd Feb at IBM, Raleigh.
Summary of actions
(MartinC): Write a clarification of the
requirement for issue 64. (Post Schema Validation) (Carried fwd from 29th Nov.)
In progress, carry until Face-to-face.
(Bryan): Move issue wsrf89 to open.
(Interop Testers): Confirm implementations,
outlook for availability & contact names via mail list. (Carried fwd from
10th Jan)
(Chairs): Add an item to the fdce-to-face agenda: discuss
the Appnotes document.
(Bryan): Raise two new issues, for discussion
when the new wsa editors draft comes out: 1) Implications of the change –
including the effect of the ‘Comparison’ text - for WS Resource spec and 2)
Implications for example messages in other specs.
(Ian): Update the priorities list (model-level issues are
high priority).
(Igor): To write up the proposal for issue 72 based on the
discussion on 24th Jan.
(Bryan) Combine issues 79 and 88 into one.
(Chairs) Continue discussion of issue 79/88 at the
face-to-face.