Notes from the OASIS WSRF TC teleconference
25th July 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=7741
NB: The
meeting is not quorate, not having the necessary 50% of voting members.
Confirm minute taker
Tim Banks is taking the minutes.
Approve of minutes of July 11th Telecon
See: http://www.oasis-open.org/committees/download.php/13534
Call
for AOB
None.
Action Review
(TomM) Post revised draft of RMD specification. Carried Fwd from June 27th.
(Bryan) Remove issue 117 (replaced by 123).
Done
(Bryan) Move issue 118 to open. Done
(Bryan) Remove issue 121. Done
(Bryan) Move issue 122 to closed, no
action. Done.
(Bryan) Move issue 123 to open. Done.
(Bryan) Reopen issue 110. Done
(Bryan) Move issue 110 to resolved. Done.
(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 119 to resolved. Done.
(Bryan) Move issue 120 to resolved. Done
(Bryan) Create new issue (ws-addr schemaLocation
trailing “/”) with a state of “resolved”. Done
(Tim) Distributed
updated primer which removes requirement on issue 123. Done
(William)
Distribute scenario description that motivates issue 123 independent of the
primer. Done
(DaveS) We need to enhance the resolution
process to enable resolutions to go into the public report at the end of the
public review process.
(MartinC) Anything that is published after
public review means we must publicize the differences compared to the reviewed
version.
(DaveS) That’s what the report is for.
New
issues to consider - Bryan
(DaveS) These are issues from the public comment and are all open. We’ll cover
them later.
Issue Review
(TimB) We should review section 3 of the
new version of the Primer recently posted here: http://www.oasis-open.org/apps/org/workgroup/wsrf/download.php/13744/WSRF_Primer%5B5%5D.doc
The third example is a version of the
shopping cart with WS Resources representing the Items in the cart.
(DaveS) So the constituent Items are
separate resources.
(TimB) Yes, this is the resolution of
issues 123 done as application-level wsdl/xsd and without changing any of the
specs.
(DaveS) The AddItem operation returns an
EPR to the new Item which allows you to talk to the item. So this is a nested
version of the first example?
(TimB) Yes. It’s a more complex document
structure.
(TimB) The last example is a group of
printers and jobs based on serviceGroup
(DaveS) It’s a serviceGroup with two
membership rules, allowing printers and jobs in,
(TimB) Yes.
(DaveS) So it’s not that each printer has a
servicegroup of jobs, but, rather that printers and jobs are modeled at the
same 'level' - i.e. without a printer 'enveloping' a number of jobs.
(DaveS) We need some volunteers to read
the primer.
Action: (Jem/RogerM)
Review the latest draft of the Primer.
Any objections to closing issue 123 as
described?
None.
Action: (Bryan) Move to closed.
(DaveS) One of the possibilities for
resolving issue 123 was to allow the MemberServiceEPR to be an optional
element. We need to decide whether to raise this as an issue. William posted
requirements here: http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200507/msg00008.html
describing a ServiceGroup which didn’t provide access to the member services.
Are there any objections to making this an issue?
None.
Action: (Bryan) Create and open a new issue.
(TomM) I’m Ok with it,
but I think ServiceGroup will be more complicated.
(DaveS) And serviceGroup
is difficult already.
(TomM) I know how to
make the syntax changes, but the changes in the semantics are difficult to
describe.
(Bryan) It could be that the whole RP doc is in
the serviceGroup, so access to the member is not necessary.
(DaveS) We could simply
include an EPR which is not useable. This is similar to providing visibility to
a ResourceProperty which a particular user can’t set.
(Bryan) This would force the implementation to
make up the EPRs.
(DaveS) The problem is
that this is a ServiceGroup, and services have EPRs. If what you’re modeling
is not services, then maybe serviceGroup is not the thing to be using, which was
the route taken in the resolution to issue 123.
(TomM) I propose we
close with no action.
(TimB) Seconded.
(DaveS) Any objections?
(BryanM) Is it an
option for William (not present) to reopen the issue if he feels strongly?
(DaveS) Ok, but it
needs stronger use cases to motivate it.
Action: (Bryan) Move to Close with no action.
(DaveS) We need to
consider comments from the public review. Note that these are prefixed ‘PR
Comment’.
(TomM) This is about whether the GED
defines the type, or whether it’s the complexType that does it.
(DaveS) The wording should change the
beginning of the sentence that starts in line 330 to: ‘This GED refers to the complexType
of.…’
(DaveS) Any objections?
None.
Action: (Bryan) Move to Resolved.
(DaveS) If the element
is a GED, it’s already uniquely identified by qname. We could fold this in with
requirement 1.
(JemT) We could say
that ‘It follows that…’
(DaveS) Right. So we
remove the separate point that distinguishes requirement 2 and change this to
say ‘It follows that…’ Any objections?
No objections.
Action: (Bryan) Move to Resolved.
(Bryan) This is pointed out on the GetResourcePropertyDocument operation,
but applies to all the operations.
(DaveS) This asks for clarification of what
it means to follow the interop requirements of the Resource Access Pattern.
(Bryan) Since we removed all embodiments except for WS-Addressing, all
this means is that one must follow the rules of WS-Addressing.
(DaveS) I don’t think it states that one
must use WS-Addressing, but there are no interoperability issues in just using
an EPR. So the issue is correct: the ‘MUST’ seems superfluous. However, I
would like to hear other opinions on this.
(TomM) We took out some requirements of the
RAP.
(BryanM) The question is whether the text
on line 372 adds anything. I don’t think so. Can we just remove the sentence?
(DaveS) That would be the proposed
recommendation. But can we make it non-normative and still reference WS-RAP?
(Bryan) Then we don’t need that document.
(DaveS) We need an action item to assess the
implications of removing this ‘MUST’ and similar reference (in other specs) to
WS-RAP. Does this remove all references to WS-RAP and make that doc
non-normative?
Action: (DaveS/MartinC)
Do the review.
Action: (Bryan) The title should be changed to “..pseudo-schema
for GetResourcePropertyDocument”
(DaveS) The response to a GetResourcePropertyDocument
must always include the root element of the Resource Property document. We
should close the issue with no action. Any objections?
None.
Action: (Bryan) Move to closed, no action.
Action: (Bryan) The title should be changed to “...pseudo-schema
for GetResourcePropertyDocument”
(TomM) Do we want to talk about the
implications of access control?
(DaveS) No, we don’t talk about any security
requirements (or associated faults) in the specs. The statement about the
response in the spec is right. There may be reasons why it might fault, the
only fault we identify is ResourceUnknown.
(TomM) We’re not saying this is an
exhaustive list of faults.
(DaveS) What the spec says is that the WS
resource should either send the right response message or a fault. Other faults
could be defined.
(Bryan) But the thinking behind the issue is wrong. We don’t need this
Access Denied Fault because the operation should not be offered to client’s
which can’t reply with the whole document. However, we lead the reader down the
wrong road in line 391. We should change it to recommend not offering the
operation if the user can’t get the whole document.
(DaveS) Maybe we could do this in the
primer or AppNotes.
(Bryan) But we should add guidance about clients that don’t have access to
the whole doc.
(DaveS) Well, it could be that a user gets
only some of the RP document (eg only a particular users jobs), but not all of
it.
There are two steps here: the issue is
resolvable with no action, since the spec is unambiguous with careful reading
of 387-390 and 391-2.
(TomM) I propose closing with no action.
(Tim) Seconded.
No objections.
Action (Bryan) close with no action.
(DaveS) We can decide later whether to help
further by putting put the resolution text in AppNotes or Primer.
Straggler Roll Call & Close
Closed 13:23 Eastern time
Next telecon is on August 8th.
Summary of actions
(TomM) Post revised draft of RMD
specification. Carried Fwd from June 27th.
(TomM) Write new text for resolution to
issue wsrf 118. (cut/copy/paste for RMD to go in AppNotes.) Carried Fwd from
June 27th.
(Jem/RogerM) Review the latest draft of the
Primer.
(Bryan) Move issue 123 to Closed.
(Bryan) Create new issue describing optional MemberEPR in ServiceGroupEntry
and move to closed, no action.
(Bryan) Move issues 125 and 126 to resolved.
(DaveS/MartinC) Issue 127: review
implication of removing every operation’s obligation to follow Resource Access
Pattern.
(Bryan) Change titles of issues 128 & 129 be changed to
“...pseudo-schema for GetResourcePropertyDocument”
(Bryan) Move issue 128 to closed, no action, but with explanation.
(Bryan) Move issue 129 to closed, no action, but with explanation.