Notes from the OASIS WSRF TC
Teleconference
31st October 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=7748
The meeting is quorate.
Confirm minute taker
Tim Banks is taking the minutes.
Approve of minutes of Teleconference on 17th
October
See: http://www.oasis-open.org/committees/download.php/14971
There were no comments and no objections to
approving the minutes.
Call For AOB
None.
Action Review
(Bryan) Move issue wsrf153 to closed. Done
(Bryan) Move issues 154 and 155
to open. Done
(TC members) to
review the AppNotes and Primer documents when posted and be ready to discuss at
the next telecon. See below
(Bryan) Move issue 154/i, ii and
iii to resolved Done
(Bryan) Move issue 155 to resolved.
Done
Review of Public comments - Chair
PR2 comments from Fujitsu
See:
http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200510/msg00030.html
(Ian) About Item 1 (RP/1447): WS Topics is pre-TC status. There
was a similarly worded comment in PR1, wasn’t this resolved?
(DaveS) I think the version reference to Topics is one PR
version behind the reference to Base Notification.
(IanR) Aren’t we ok to use non-TC versions? We have done so
before provided we are based on PR drafts.
(DaveS) It’s curious that there are refs to PR drafts for
Base Notification and Topics, but the comment is only about Topics: we need
some clarification.
(IanR) I propose we should respond that the WS-Topics spec
has PR status and that this is not an issue.
(DaveS) I think so. It’s not a burning issue until we go
forward to a standard, when we should have more stability.
(IanR) Ok – about item 2 (unexplained wsnt: prefix): What do
SteveG and JemT think? We could remove the prefix, or add the prefix in the
namespace table (section 1.3), but the latter might imply the spec is required.
(SteveG) The document doesn’t say the prefixes are needed –
they are just used in the document. We should check why we removed it – we
don’t want to undo something important.
(IanR) Ok. Item 3: (Normative references to WS-Topic). We
can respond in the same way as for item 1.
(DaveS) Except that the URL in the reference is wrong.
(SteveG) I’ll look into it.
(IanR) Item 4: The reference to Base Faults is an editorial
problem.
(IanR) Items 5 … 11 are effectively the same as item 1.
(IanR) Item 12 seems to be a misunderstanding – AppNotes was
not part of the Public review this time. None of these items seems to be
substantive.
Action: (Ian) Send a note to the editors to describe the
required editorial changes.
PR Comments from Mark McKeown
See http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200510/msg00032.html
(IanR) Line 117 of WS Resource - use of ‘logical’ in the
definition of a resource.
(DaveS) It seems clear to me – it’s not a physical thing.
(IanR) I will respond with clarification – no change is needed
to the spec.
(DaveS) Yes, this is not normative language.
(IanR) Any objections?
None.
(IanR) Line 118: there is an unused reference to URI, but we
don’t relate the resource identification to the URI; it is
implementation-dependent and not a URI. We could remove the ref to URI
following the recent removal of text that used the reference, but we don’t need
to.
(DaveS) Right, it’s a harmless reference.
(IanR) So we should simply respond by clarifying what the
spec means: resource identifiers are not URIs. Any objections?
None.
(IanR) Line 122 (text and diagram inconsistent): The issue
says the definition of WS Resource is unclear. (“A WS Resource is a Web Service
through which a resource can be accessed.”) Should we say that the WS Resource
is the aggregation of the Web Service and the resource that’s accessed through
it?
(DaveS) This seems wrong.
(IanR) I propose that we updated line 122 to say “WS
Resource is the composition of a resource and a Web Service providing access to
the resource”.
(DaveS) I second that.
(IanR) Ok. So that could be considered substantive. I don’t
consider it so, but if it is, we would need to go through another 15 day public
review period. Does anyone think it is substantive?
(BryanM) This seems to be restating what the TC was thinking
all along.
(TomR) Does this affect anything on the wire? I think not.
(DaveS) No. Nothing.
(IanR) So, this is an action for the editors, and we should
make this into an issue.
(BryanM) Issue 156 is this list of comments from Mark.
Action: (BryanM) More to resolved.
(IanR) At line 140 – the semi-circle in the picture is the
Web service interface. Do we need to clarify this, and in other diagrams?
(TimB) Why don’t we remove the semi-circle? It’s not adding
anything to the diagram, which is about identification of the WS Resource and
Web service.
(IanR) Any objections to this, and to considering it a
non-substantive change?
No Objections.
(IanR) Lines 137-138 (inconsistency): this is cleared up by
the clarification of the definition of WS Resource.
(IanR) Line 148 (Examples): We don’t need to use
non-normative examples – we could respond to the comment saying that
(TimB) This might be affected by the comment about the TAG
recommendations.
(IanR) Ok – so, line 148: The Tag recommendation. See: http://lists.w3.org/Archives/Public/www-tag/2005Oct/0057.html
(IanR) We should respond that WS-RF makes no normative
constraints on the EPRs. Users should do as they wish with WS-Addresssing
(TimB) What about the examples?
(IanR) They are non-normative.
(DaveS) We could use URI-only examples and deflect some
attention.
(SteveG) Or take the examples out…
(IanR) The examples were included as a result of PR1
comments.
(SteveG) Pragmatically, the best things is to take out the
reference parameters
(DaveS) We could change the example – that would make the
people at Tag more comfortable with our spec. It makes no difference to the
spec itself.
(IanR) So, how strongly do people feel?
(DaveS) We are not fussed. Down the road we may not use ref parms,
but now we do.
(IanR) So the motion is to replace the examples, to use
parameter extensions to the URI instead of reference parameters. Any
objections?
None.
(DaveS) So this is a clarification. What about the
substantive nature of the change – we are just changing examples.
(IanR) Right.
No objections.
PR2 comments from Ramya Nagarajan
See http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200510/msg00033.html
(IanR) This is about the UPA constraint and a validation
error in the ServiceGroup schema.
(BryanM) We could move the ‘any’ above the RPDoc element,
but will we ever need a content element that’s I the SG namespace.
(SteveG) That should not happen. I agree with the fix – it
should be ‘other’
(IanR) Any objections?
None.
(IanR) Is this a substantive change?
(SteveG) The only people who will notice are those using SG
namespace elements; it’s a corner case.
(IanR) Any objections?
None.
(Bryan) It’s interesting, because the SG schema might need
to be revved to a new namespace, and references to it would need to be changed.
(IanR) We could change the schema without revving
(DaveS) Don’t we need to change the schema name anyway?
(IanR) No. We can just replace the schema at it’s current
location.
(TomR) Someone might have implemented using the PR2 version.
(DaveS) They a very unlikely to notice the change..
(Bryan) …but it is becoming more restrictive, except that is
broken now because of the UPA constraint.
(TomR) I’d rather bump the revision…
(IanR) But there is a more work required to do that.
(StevG) We could send WSDM and WSRF mailing lists a note warning
of the change.
(IanR) That is a pragmatic solution. The proposal is to fix
the schema without changing the namespace/URI, and send emails to warn of
changes.
(TomR) We should hold this until we have finished public
review?
(IanR) There are not many PR comments left.
PR2 comments From Masahiro Kurosawa
See http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200510/msg00034.html
(BryanM) This is a follow-up to issue 154.
(TimB) This is about the use of the composite interface in
the MemberInterfaces attribute vs the components.
(IanR) How do we know which portTypes are there without portType
inheritance?
(TimB) By the operation being there.
(IanR) We have already said in issue 154 that the portType
is what’s important.
(TimB) It’s possible to put the components or the composite,
or all of them. Provided the service implements them.
(DaveS) We can put in the primer that the contentrule/content
can include information from any other sources – eg the spec for Lifetimes.
It’s handy to put constituent interfaces in MemberInterfaces.
(FredC) So there’s a kind of best practice to say that the Interfaces
info is useful, but not necessary.
(IanR) What’s the proposal?
(DaveS) The simple answer is ‘yes’ the assertion in the
comment is correct: imcluding component interface info is useful.
(TimB) I could add a note in a box to say that this, though
currently the example uses only the composite.
(DaveS) I would prefer we had an example which used the
components.
(IanR) Why would we put this in the primer and not in the
spec?
(DaveS) The normative statement in SG says that the MemberInterfaces
are the ones that must be implemented by the MemberService. We don’t make any
statement about what’s useful additional info.
(BryanM) It’s odd to use MemberInterfaces to require a set
interfaces when only a single can be exposed.
(TimB) Yes: the composite interfaces defines its derivation;
why would we expect this info to be in the MemberInterfaces attribute?
(BryanM) We seem to need a better explanation of MemberInterfaces.
(IanR) Which should be in the spec.
(TimB) We don’t want to insist that MemberInterfaces must
contain all component interfaces – that could be a long list.
(IanR) We don’t want to say MUST, nor SHOULD. The attribute
should be the aggregate portType.
(TimB) The derivation info is contained in the wsdl.
(DaveS) Is it?
(TimB) The wsa:action attribute contains the info. So the
spec should say that the recommended way is to put the Aggregate info in the MemberInterfaces.
(FredC) In real life it’s the messages that matter, so there
may be some way to identify the Lifecycle portType in the composed portType via
the operation.
(SteveG) The action URI must be in the WSDL – that does it.
(IanR) Actually, the action URI is in appnotes – it’s
non-normative.
(SteveG) But the WSDL attribute way is the only way to make
it work, so it’s clear how to identify the portTypes.
(IanR) Two approaches are to clarify in the spec that the MemberInterface
attribute is intended to be the composed portType and say in Appnotes that listing
components is possible OR to say in the Appnotes section on portType
composition that this can also be exploited by ServiceGroups that get partial
info about MemberInterfaces supported by a MemberService.
(TimB) I prefer Appnotes; there’s nothing normative to be
changed.
(IanR) Is there anyone who thinks changes are needed to the ServiceGroup
Spec?
(BryanM) Don’t we need to decide between one or the other?(DaveS)
I might be interested only in some component of the services in the group. SG
needs to b able to do this.
(BryanM) What does the spec say now?
(DaveS) Members must support the portType.
(BryanM) Interesting: there is only one interface – it’s
made of copy/pasted operations.
(IanR) Could we get a proposal for appnotes changes?
Action: (Tim/Dave) Propose text via distribution list
for inclusion
(BryanM) Should we reopen issue 154?
(IanR) Yes.
Action: Move issue 154 to open?
(IanR) We can go back around to the schema: I propose we
make the change without changing namespace and alert potential implementers via
mailing lists. Any objections.
None
Action: (BryanM) Move issue 157 to resolved
Comments on Application
Notes document of Oct 20 - Create a review team if required.
(IanR) We should have a team to do this – spec editors
should do this – is that possible?
No objections.
(IanR) Would anyone else like to join?
None.
Action: Spec Editors – review AppNotes and send
comments to the list by Nov 14
Comments on Primer document updated on Oct 21
(IanR)Are there people who would be willing to review the
primer?
(JemT) I have started.
(IanR) I will do this too
Action: Jem and Ian to review
Comments on ResourceMetadataDescriptor
document updated on Oct 30.
(IanR) Dave has volunteered to review this. Can Bryan do it
too?
(Bryan) Ok.
Action: Dave and Bryan review by next TC.
AOB
(IanR) Is the next telecon date Ok?
(SteveG) Thanksgiving is 24th,
but will not affect us.
(IanR) Next meetings are on 13th
and 27th .
[Correction – should be Monday 14th
and 28th Nov
See http://www.oasis-open.org/apps/org/workgroup/wsrf/calendar.php
]
Straggler Roll Call
Closed 13:30
Summary of actions
(Ian) Send a note to the editors to describe changes
required in answer to Fujitsu comments.
(BryanM) More issue 156 (McKeown comments) to resolved.
(BryanM) Reopen issue 154
(Tim/Dave) Propose text for resolution of issue 154 via
distribution list.
(BryanM) Move issue 157 to resolved
(Spec Editors) Review AppNotes and send comments to the list
by Nov 14
(Jem/Ian) Review Primer and send comments to the list by
Nov 14
(Bryan/DaveS) Review updated RMD by Nov 14