Notes from the OASIS WSRF TC teleconference
22nd August 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=7743
Confirm minute taker
Tim Banks is taking the minutes.
Approve of minutes of August 8th Telecon
See: http://www.oasis-open.org/committees/download.php/13996
There were no comments and no objects to
approving the minutes.
Call
for AOB
None.
Action Review
(TomM) Post
revised draft of RMD specification. Carried Fwd from July 25th.
(TomM) Write new text for resolution to issue wsrf 118. (cut/copy/paste for RMD
to go in AppNotes.) Carried Fwd from June 27th.
(Bryan) Move issue 123 to
Closed. Done
(Bryan) Move issue 138 Open. Done
(DaveS)
Investigate the implications of the resolution of issue 137 to make MemberserviceEPR
optional. Work on precise language with Tom. Carry Fwd
(Bryan) Move issue 137 to resolved.
Incorporate any implications for the spec from Dave/Tom. Carry Fwd
(IanR) Produce
detailed resolution text for issue 127. Done
New
issues to consider - Bryan
Issue WSRF139: Number of messages needed to retrieve the content of a service group
See email: http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200508/msg00017.html
(William) This is about a simple service
group that needs to send a lot of messages to gather information.
(DaveS) Is this a reasonable issue? Does
any object to opening it? Ian’s response that it may be two issues:
simplifying the model, and removing the statement about authoritative
membership.
(William) So this is about the number of
messages, concerned with the authoritative way to determine membership.
(DaveS) So this sounds like an issue, well
discuss splitting when we discuss in detail.
Action (Bryan) Move to open.
WSRF140:
Constraints on use of schema for resource properties document
See http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200508/msg00022.html
(Bryan) There is a list of rules restricting the definition WS Resource RP
documents. We should be more liberal so that existing apps don’t have to
change their xml.
(DaveS) Ian pointed out that we need to
think about happens if a document has stuff preceding the first qnamed property
(rule 4).
(Bryan) We already have ways of retrieving partial documents. It’s a
question of what is needed, if qnamed properties are needed, the app should do
that, but we should not insist on it.
(DaveS) We need to figure what happens with
commands that respond with qnames.
(Bryan) Yes, we would need to discuss that.
(DaveS) Why could we not wrap the xml
document inside a single ResourceProperty?
(BryanM) That seems to be a wrapper simply
for the sake of the wrapper. Also what’s the point of getResourcePropertyDocument?
(DaveS) This comes down to whether
exploitation of WSRF needs the introduction of ResourceProperties, like
lifetime, anyway.
Action (Bryan) Move the issue to open.
Issue
review - Chair
WSRF118:
How do you cut/copy/paste portions of metadata from other interfaces into a new
metadata document
(DaveS) We need to postpone this as Tom is not on the call.
WSRF127: PR Comment – Why MUST for “Resource Action
Pattern”?
Emails were posted (see http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200508/msg00020.html)
(DaveS) This removes the definition of “ResourceAccess
Pattern” in favour of referring to a WS Resource defined by the WS Resource
spec. This addresses the issue raised in the public comment.
(William) I was looking at the definition
of WS Resource (several bullet points). Ian explained why the first two bullets
are needed, but still I don’t agree: WS Addressing says that the messages must
put the reference parameters in the message to identify the resource.
(DaveS) So the bullet is ensuring that the
WS Addressing binding has the parameters.
(William) Repeating the information for the
sake of clarifying is bad practice in normative specs.
(DaveS) I’m inclined to agree, unless this
is absent from the WS Addressing core. If it’s only in the SOAP binding then
we still need this text, to protect ourselves against other bindings.
(William) Surely a new binding wouldn’t
ignore the reference parameters: that would be a broken binding.
(DaveS) I propose we delete the second
bullet, and put a note in the public comment response that we are relying on
the behaviour of WS Addressing bindings.
(William) That would be true of any use of EPRs.
I second the proposal.
(DaveS) Any objections to accepting Ian’s
proposal of August 12, but with the removal of bullet 2, and adding a note in
the PR response to explain that we need the binding to contain the identifier as
reference parameters in both reference and messages.
No Objections.
WSRF130: PR Comment – fault for operation not supported
(TimB) This asks for a universal fault that
reports if an operation is not supported.
(DaveS) This would be used if a client
discovered a WS Resource, but did not look at the WSDL. For OGSA basic
profile, there is a ResourceProperty to describe the portTypes that are
supported, thus avoiding issuing unsupported operations without bothering with
WSDL.
(TimB) I propose that we don’t change
anything because the information is in the WSDL; we should not change the specs.
(William) Seconded.
(DaveS) This is supported by binding-level
messages, and by application-level information in more dynamic environments.
Action: (Bryan) Move to closed, no action. With
explanation.
WSRF131: PR Comment – correct use of MAY in GetMultipleResourceProperties
(TimB) This is about line 566 in wsrf-rp. The components of the request message
are optional in the schema.
(DaveS) Could we simply delete the
sentence? Or would we lose the normative statement altogether, since the
pseudo-schema above line 566 is non-normative - our precedence rules make the
text normative. We can close with no action, but explain the importance of
this normative text to ensure that the component may be included.
No objections.
Action: (Bryan) Move to closed, no action. With
explanation.
WSRF132: PR Comment – how does permission to access a
property affect the response of GetMultipleResourceProperties?
(TimB) This is a question about a property
which is defined as minoccurs=0 but which exists in the instance document, but
the requester doesn’t have permission to see it.
(IanR) I don’t think minoccurs makes any
difference. The property exists, but it can’t be shown. The request must fail.
(DaveS) The text says that if the response
message can’t be returned, it must fault. So the answer to the issue is that it
must fault, but we need to clarify that the correct response contains all the
elements that should be returned, and if not than a fault is required. We
deliberately don’t say what the fault is.
(Ian) I propose this is the resolution, but
we need to clarify that if there is a correct response then all of the elements
that should be returned have been.
(DaveS) The need for this clarification
probably exists else where. This is a change compared to OGSA where security
permissions silently filtered the information presented back to the requester.
Is there a seconder for Ian’s proposal?
(TimB) Seconded.
Action (Bryan) Move to resolved with two
consequences: a) Spec changes are needed to clarify the text in the response to
getMultipleResources (all properties that are present in the RPdoc must be returned
else a fault) and b) check whether this ambiguity doesn’t exist elsewhere.
WSRF133: PR Comment – clarify the fault to be returned when a request specifies
a QName that cannot exist in the resource property document
(IanR) The issue says a fault is needed,
but why doesn’t it say which one? It could respond with InvalidResourcePropertyQname.
(DaveS) Or a fault derived from InvalidResourcePropertyQname.
(IanR) We haven’t used that kind of
language elsewhere.
(DaveS) But it is implied by the definition
of the fault.
(IanR) I propose that we adopt this
suggestion and specify the fault explicitly.
(DaveS) Yes and the name of the fault is
text is out of step with the schema – it should be InvalidResourcePropertyQnameFault.
(Agreed)
(DaveS) That’s the proposal, any
objections?
None.
Action:
(Bryan) Move to resolved.
AOB
(TimB) Is the next phone call on Sept 5th.
(JemT) That is Labour day in the US.
(DaveS) And the preceding week is a holiday
in the Uk. We could cancel this
phone call since we are in good shape. Any objections?
None.
Action: Cancel
phone call on 5th Sept. Next meeting is 12th Sept in London.
Straggler Roll Call & Close
Closed 13:30 Eastern time
Summary of actions
(TomM) Post revised draft of RMD
specification. Carried Fwd from July 25th.
(TomM) Write new text for resolution to issue wsrf 118. (cut/copy/paste for RMD
to go
in AppNotes.) Carried Fwd from June 27th.
(DaveS) Investigate the implications of the
resolution of issue 137 to make MemberserviceEPR optional. Work on precise
language with Tom. Carried fwd from 8th Aug.
(Bryan) Move issue 137 to resolved. Incorporate any implications for the
spec from Dave/Tom. Carried fwd from 8th Aug.
(Bryan) Move issue 139 to ‘open’.
(Bryan) Move issue 140 to ‘open’.
(Bryan) Move issue 127 to ‘resolved’ based on IanR’s proposal of August
12, but with the removal of bullet 2 from the definition of WS Resource.
(Bryan) Move issue 130 to closed, no action. With explanation.
(Bryan) Move issue 131 to closed, no action. With explanation.
(Bryan) Move issue 132 to resolved, with explanation and action to check
for other cases of the same ambiguity in returning fault vs complete RPDoc.
(Bryan) Move issue 133 to resolved.