Notes from the OASIS WSRF TC teleconference
8th 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=7742
Confirm minute taker
Tim Banks is taking the minutes.
Approve of minutes of July 25th Telecon
See: http://www.oasis-open.org/committees/download.php/13762
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.
(Jem/RogerM) Review the latest draft of the Primer. Done
(IanR) Was there enough feedback?
(TimB) There was a suggestion that we could
consolidate the examples on a single scenario.
(IanR) I think there are four scenario types using the shopping cart and the
printer. These are simple, and it would be hard to imagine a single scenario
that would do the job.
(TimB) Right, it was hard to imagine a
reasonable example for get/putResourceProperties document for the printer.
(DaveS) Right, if we tried to reduce it to
one scenario, we don’t have enough complexity with a single scenario.
(JemT) I didn’t see any problem switching
(KirkW) The switching was confusing – the
order could be better if it were printer properties, then simple shopping cart,
complex shopping cart, then Printer service group.
(TimB) Well, the first section also deals
with how WSRF puts identifiers in message headers – it would be confusing also
to be dealing with complex operations at the same time. Perhaps the first
example could be a simplified get/set property.
(IanR) Do subsequent sections follow
ordering introduced in section 3?
Yes.
(Bryan) Move issue 123 to Closed. (Carried
fwd)
(Bryan) Create new issue
describing optional MemberEPR in ServiceGroupEntry and move to closed, no
action.
(IR comment: Dave S requested the issue (137) be reopened). Done
(Bryan) Move issues 125 and 126
to resolved. Done
(DaveS/MartinC) Issue 127: review implication of removing every operation’s
obligation to follow Resource Access Pattern. See below
(Bryan) Change titles of issues
128 & 129 be changed to “...pseudo-schema for
GetResourcePropertyDocument” Done
(Bryan) Move issue 128 to
closed, no action, but with explanation. Done
(Bryan) Move issue 129 to
closed, no action, but with explanation. Done
New
issues to consider - Bryan
Issue WSRF138: Typo in title of section 5.1.1
(IanR) Any objections to this being opened?
None
Action (Bryan) move to Open
Issue
review - Chair
WSRF137:
Allow the MemberServiceEPR to be optional element in a ServiceGroup
(William) One scenario is if the serviceGroup
is behind a firewall, and the EPRs can’t be exposed, but one wants to expose
the status of Printers (toner etc) to suppliers. It needs to be done without
giving direct access because there may be another way for the external users to
get to the printer services. The problem is that if we don’t make the EPR
optional, then people will make up something bogus.
(IanR) What are the arguments against this
proposal from two weeks ago?
(DaveS) The changes needed to make the EPR
optional were extensive, and we would end up with a serviceGroup that has no
services in it. A compromise is to say that the services must exist, but the exposure
of the EPR is optional, but I haven’t discussed this with Tom.
(TimB) What does it mean to say that a
service must exist without there being an EPR? There is no normative meaning to
the existence of the service.
(WiallimV) The fear is that people can use ServiceGroup
without any service, but we need to make it clear that it really must be there.
It’s not something that can be verified, but this is just like a lot of other
parts of the text.
(DaveS) Hopefully we can make the textual
changes assuming the service exists, and only when we explain the MemberServiceEPR
do we explain what optional means: it should exist, but isn’t exposed.
(IanR) We don’t need to make a big deal
about the existence.
(DaveS) Right, we just imply it exists, but
we’re not exposing it.
(IanR) So the proposal is to make the
change for optional EPRs. Do we have a seconder?
(?) Is there another example of how to use
this?
(William) If access to resources is centralised
in a registry, the installation might put a lookup key in the resourceProperties
which goes into the serviceGroup, instead of an EPR.
(Fred) I’ll second it.
(IanR) Any objections?
None.
(IanR) So this is resolved.
(TimB) I don’t think we can move this
directly to ‘resolved’ – we’ve resolved to work on a proposal.
(DaveS) We’ll need to come back and verify
it.
(IanR) We might uncover problems along the
way, but the decision is clear.
(MartinC) Yes.
(SteveG) I think we need to analyse the
implications of making it optional.
Action: (DaveS)
Investigate the implications and work on precise language with Tom.
Action: (Bryan) move to resolved, but incorporate any
implications for the spec from Dave/Tom.
WSRF118: How do you cut/copy/paste portions of metadata from other interfaces
into a new metadata document
(IanR) We should skip this since Tom is not
present.
WSRF127: PR Comment – Why MUST for “Resource Action
Pattern”?
(IanR) There’s been some email, exchanges
about this. The action last time for Dave/Martin was to review the implication
of removing the reference to RAP.
(DaveS) The action was to review the specs
to see what effect there would be of removing refs to RAP. In fact, all the
normative refs are those referred to in the public comment. So if we address
the public comment, that’s the whole story.
(IanR) So, what is the proposal?
(DaveS) The implied proposal was that we
could delete WS-RAP from our specs, if we accept the fact that there is no
interoperability problem resulting from the loss of ‘MUST’.
(IanR) I think there is an interoperability
problem: the RAP document is where the requirement for the identification of
the resource in the message is explained. It normatively depends on
WS-Addressing to provide the identification. Dave pointed out the singleton
pattern, but this is covered by the case of an EPR where the identifier is part
of the address. I made a proposal here: http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200508/msg00003.html
to improve RAP because we removed too much detail when we moved text to AppNotes.
(William) I don’t see why the identifier is
needed: WSDL messages rarely have identifiers in them and the service/port is
enough to identify the service. Another example is WS-MetadataExchange can get
WSDL for a Web service without having explicit requirements to carry an
identifier.
(SteveG) Perhaps WS-Mex is not sufficiently
specified?
(MartinC) I don’t see why we need the
indirection. We only use WS-Addressing.
(IanR) We need to say that we depend on
WS-Addressing.
(MartinC) Right, but we don’t need to talk
about RAP, identifiers in messages and so on, we just need to say we use
WS-Addressing to address resources.
(IanR) Right, that’s what WS-RAP says.
(William) But why the level of indirection?
Why not just say that we use WS-Addressing?
(DaveS) The public comment is asking about
the use of ‘MUST’ wrt interoperability of messages. I think we mean the
identifier must be in the message, not necessarily in the address.
(IanR) No, the use of the word ‘message’
means anywhere in the message.
(DaveS) In that case what is it that WS-RAP
says, normatively?
(IanR) It says use WS-Addressing.
(DaveS) But a URL will do the trick: we say
WS-Addressing is needed, but a URL will work.
(MartinC) I don’t agree. A WS-Resource
can’t be accessed except by using WS-Addressing.
(DaveS) Well, life is easier if we all use
WS-Addressing, but it’s not an interoperability problem. We need to get this
clear.
(William) I agree.
(SteveG) No – it’s an interoperability
issue. A WSDL document might contain portTypes etc etc and a Service element,
but forgets to say that an EPR is really needed to access the service. The
Service element might be for metadata exchange, for example. This would be an
interoperability problem unless we have a statement explaining the semantic
requirement to use an EPR. It’s the combination of the WSDL and the SOAP header
that makes the service work.
….
(MartinC) Are we still agreeing that EPRs
are necessary?
(IanR) Yes. We have a public comment
asking is we this is really an interoperability requirement.
….
(William) I’m against inventing a “Resource
Access Pattern” when all we’re saying is that people should use EPRs.
(IanR) We could refer to WS-Addressing
directly and remove the indirection.
(William) I think that would be progress.
(MartinC) Yes.
(IanR) But the WS-Resource spec itself may
still be needed, since it defines what a WS Resource is.
(DaveS) Yes, there are normative
requirements separate from the “RAP” term.
(IanR) We could make RAP non-normative.
(MartinC) I don’t think we need the term.
(William) It’s not clear to me that we
still need the WS-Resource spec.
(IanR) We would have to put the definition
of WS-Resource (and the requirement to use WS-Addressing) somewhere.
(IanR) I could redraft WS-Resource to make
“RAP” non-normative and replace normative refs to it from other specs.
(DaveS) We need to makes sure this
addresses the public comment, which pushes on whether WS Addressing is needed.
(IanR) The comment asks whether “RAP” is
required. There is a requirement to have an identifier in the message.
(MartinC) Without “RAP” there is no issue.
(IanR) My impression was that the
definition of “RAP” was unclear, but the MUST is still required to say
something about the need for identifier. Does clearing this up resolve the
issue?
…
(TimB) It does. WS Resources must use
WS-Addressing.
(DaveS) Ok, yes. So, if we clean up the
text as Ian suggested, or remove the indirection, that will make the normative
requirements clear. The Primer can also make clear what WS Addressing does.
…
(William) What more do we need to say other
that we use WS Addressing? We can get rid of the WS Resource spec.
(IanR) There’s more to WS Resource than
using RAP.
…
(William) The only thing I see is that the RPdoc
must be defined use XML, and use messages defined by WS-RP.
(IanR) Right, and this is pulled together
in a single spec.
(William) I propose that in WS-RP we say
WS-Addressing is needed, and that XML is needed.
(MartinC) No. The issue is the indirection
via RAP.
(William) I want to go further.
(IanR) In Summary, the proposal is to
replace normative refs to “RAP” in the WS-Resource spec with references to WS-Addressing
in all specifications and to confirm in the response to the comment that it is
a normative requirement. Also to check whether the use of “RAP” is still
needed.
(MartinC) Seconded.
(IanR) Any objections?
(SteveG) I object – I think removing the concept
also loses context.
(IanR) We only have 5 mins left, let’s
continue via email or at the next call.
(MartinC) We could debate more and vote.
Does anyone want to debate more?
(SteveG) I think we disagree, there’s
nothing more to say.
(IanR) I propose to produce a version of
the spec and we can vote on it next week.
(MartinC) That’s a little irregular, but
Ok.
Action: (IanR)
Produce detailed proposal.
Straggler Roll Call & Close
Closed 13:30 Eastern time
Next telecon is on August 22nd.
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.
(Bryan) Move issue 123 to
Closed.
(Bryan) Move issue 138 Open.
(DaveS) Investigate the implications of the
resolution of issue 137 to make MemberserviceEPR optional. Work on precise
language with Tom.
(Bryan) Move issue 137 to resolved. Incorporate any implications for the
spec from Dave/Tom.
(IanR) Produce detailed resolution text for
issue 127.