Notes from the OASIS WSRF TC
Teleconference
14th November 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=7749
The meeting is quorate.
Confirm
minute taker
Tim Banks is taking the minutes.
Approve
of minutes of Teleconference on 31st October
See: http://www.oasis-open.org/committees/download.php/15171
There were no comments and no objections to
approving the minutes.
Call For AOB
None.
Action Review
(Ian) Send a note to the editors
to describe changes required in answer to Fujitsu comments. Done
(BryanM) More issue 156 (McKeown
comments) to resolved. Done
(BryanM) Reopen issue 154 Done
(Tim/Dave) Propose text for
resolution of issue 154 via distribution list Done
(BryanM) Move issue 157 to
resolved Done
(Spec Editors) Review AppNotes
and send comments to the list by Nov 14 Comments from Tim and Dan, Reviewed by
Ian wrt WS Resource (with no issues).Carry Fwd.
(Jem/Ian) Review Primer and send
comments to the list by Nov 14 Carry fwd
(Bryan/DaveS) Review updated RMD
by Nov 14 Carry Fwd
Review of Public comments - Chair
(DaveS) Two new comments were received concerning
BaseFaults and answered by Ian:
See http://lists.oasis-open.org/archives/wsrf-comment/200511/msg?list_name=wsrf-comment&monthdir=200511&msg=msg00000.html
And http://lists.oasis-open.org/archives/wsrf-comment/200511/msg?list_name=wsrf-comment&monthdir=200511&msg=msg00001.html
(IanR) One was a suggestion which
contradicted previous TC decisions, the other was about a particular tool.
New Issues. (Bryan)
Issue 156 & Definition of WS Resource wrt Primer.
(DaveS) Issue 156 is resolved, but Kirk
made some follow-up comments.
See: http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200511/msg00002.html
and http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200511/msg00007.html
(Kirk) This is about the definition of ‘resource’ is it only
logical, or physical too. Tim has explained that there is not an inconsistency,
but the statement in the Primer needs expansion to round out the definition/terminology
wrt WS Resource.
(DaveS) So can we continue without reopening issue 156, but
updating the Primer. Any objections?
None.
Action: (TimB) Make updates to Primer.
(BryanM) Issue 158 and 159 are new numbers since last time
(IanR) This was discussed at the last week
. It needs to move to resolved.
Action: (Bryan) Move issue 158 to resolved.
(IanR) This was discussed at the last week
. It needs to move to resolved, the same applies to issues 160 and 161 on BaseFaults
and ServiceGroup
Action: (Bryan) Move issue 159, 160, 161 to resolved.
(Kirk) These are stylistic comments on the introductory
chapters.
(TimB) These are resolved by making the updates as suggested
in the proposal.
Action: (BryanM) Move to resolved
See: http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200511/msg00008.html
(DaveS) Are there any objections to opening this?
None.
Action:(Bryan) More to Open.
(DaveS) So, we’re left with 118 (cut/Copy/Paste for
metadata) 154 (MembershipContentRule) and 163 (RMD extensibility) that are
open.
Steps to Committee spec - chair (Pending from last call)
(DaveS) We have no news about progress on WS Topics.
(IanR) We need the editors to complete on editorial changes
and upload then we can consider them for committee drafts.
(DaveS) We still need to get a PR draft of Topics from the
WSN group, to replace the working Draft which we currently refer to, then we
can go forward to committee spec which is organised by OASIS.
OASIS Symposium 9-12 May: The Meaning of Interoperability
(DaveS) This is for the attention of the the TC. We need to
anticipate participation in this meeting, and we might think about doing a Face
to face (mtg is in San Francisco), or doing a paper on interoperability.
WSDM Comments on RMD – Heather Kreger (Issue 163)
(DaveS) Additional requirements for metadata,
have been suggested by the WSDM TC, such as Notification of relationships.
(Heather) We need an extension point so
that RMD is a metadata document for the WS Resource rather than only metadata
about properties. WSDM can define its own metadata for various reasons (info
about operations, about capabilities, about relationships) and we want those to
be in one metadata document rather than create new documents for them.
We might want to put information about
Topics that are published.
(DaveS) Topics would already be properties,
so the properties element would already be sufficient.
(Heather) These things aren’t really
defined yet – apart from the metadata about operations - but we are asking that
WSRF consider that there are additional requirements.
(IanR) What is the concrete requirement?
(Heather) We need the Any element added
back to the top-level in the RMD document.
(DaveS) So you want 0..* of Any?
(Heather) Yes. The three points behind this
facility are (See http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200511/msg00008.html
)
[Metadata about Relationships,
notifications, operations, associated policies or agreements.]
(DaveS) Let’ consider operations. What’s
needed here?
(Heather) WSDM wants to record which management
capability (WSDM 1.1) an operation is associated with, and what preconditions
are needed for it, and the postconditions. Those things are defined, and in the
future we also need to know about idempodency: can we safely re-invoke
operations.
(DaveS) These things would be static wrt
the portType definition – effectively it’s an annotation of the WSDL. (Rather than
on the properties ).
(Heather) We can’t have it in the WSDL,
because this kind of information can be independent of the operation signature.
(DaveS) The idea of the metadata is that it
is a descriptor about the properties which is required before the operation is
invoked. Is the new requirement of this same nature? Does it affect the way one
makes tools rather than the way one discovers?
(Heather) Yes. It’s about how a manager
uses it.
(DaveS) All of this could be wrapped up in
properties, for example a property describing the idempotency of operations.
(Heather) It’s important to separate data from
resources from metadata about resources. Otherwise it gets too complicated.
(DaveS) The distinction is that the
metadata is static. If the data is dynamic, then it can be expressed as
properties.
(IanR) That is the point of the RMD spec –
to keep them separate.
(DaveS) But sometimes it doesn’t always
happen – dynamic metadata gets mixed in with properties.
(Heather) An example might be timescales on
metrics, which we represent as attributes [on messages] they come back on every
message.
(DaveS) Any more questions
(IanR) Are we discussing opening the issue?
Or do we have a proposal?
(DaveS) We have an open issue, so we are
discussing the issue.
(IanR) So the proposal is to put back the Any?
(DaveS) Yes, as a child of the top-level
element.
(SteveG) Will we violate the UPA
constraint?
(DaveS) It should be Any with namespace
other.
(Fred) I think there is only one element,
and we are adding another after it.
(Bryan) The property element is optional, so we can’t follow it with Any.
(DaveS) There is a documentation element
also.
(Bryan) We need to put Any with namespace=other, or put Any at the
beginning.
(DaveS) Right, we know how, but should we
do it.
(IanR) Why wouldn’t we?
(TomR) Is this a substantive change?
(DaveS) This document isn’t in public
review.
(IanR) Seems to me we don’t aggressively put
extensibility in until we have an identified a use case, but now we have one.
(DaveS) Ok. We can extend things explicitly
if we want to, based on experience with the Any.
(TimB) Are there any limits on the use of
the Any? Can it be abused? Are there things that should go in other documents
and not in RMD?
(DaveS) If one had a mechanism to get the
metadata, we need to define how a client responds to things that it can’t
understand. Does the client need to understand, (which affects
interoperability) or can it ignore what it doesn’t understand (which constrains
the Any). We need to say that ignorance is acceptable.
(Fred) This amounts to saying what RMD is
good for. Surely we already have that statement. We might need more text about
the use of the Any.
(?) We should be ok saying that clients may
ignore what is not understood.
(Heather) WSDM Would be OK with that.
(Fred) That is the definition of an
optional Any.
(TimB) Ok
(DaveS) Any more comments? The motion is to
add Add an Any, namespace=other with description to say that the client may
ignore any information in the Any.
Any objections?
None.
Action: (BryanM)
Move to resolved.
Issue WSRF118: How do you cut/copy/paste portions of
metadata…
(IanR) This is about removing text from RMD
into the AppNotes. It is out of the spec, but not into the AppNotes.
(DaveS) Is there anything new about this or
is it the same as the portType cut/copy/paste
(Dan) It’s the same kind of thing
(DaveS) So we should take it out of the
spec, but we can’t put it into the current Appnotes because that might hold up
the rest of the AppNotes
(IanR) Revising the apnotes is easy at a
later stage.
(DaveS) So we should put this in a ‘holding
tank’ and put it into AppNotes when we produce the RMD spec itself.
(Dan) The text is in section 7 para 2 of
version wd-4 of RMD.
(DaveS) This text can be cut out and
included in the Issues doc for later movement.
(BryanM) The whole, or just the last part.
(DaveS) Let’s copy the whole paragraph, and
rework the paragraph in RMD.
Any Objections?
(DaveS) We
also need to change the contact from Tom Maguire to Dan.
Action Move
to Resolved.
(TimB) The proposal is here: http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200511/msg00006.html.
(DaveS) This doesn’t require any changes in
the schema.
(TimB) No - it exploits a natural
non-normative extension of the SG semantics.
(DaveS) Existing Globus implementations use
a different method: they document the components in the MembershipContentRule.
I’m not happy with this. An alternative is to clarify the SG spec, but it would
be non-normative.
(TimB) Where in the spec is clarification?
(DaveS) It’s line 282 in the spec – MemberInterfaces
is a list of Qname.
(IanR) Line 299 doesn’t allow anything
information about the derivation of the portType.
(DaveS) Right, so it would have to be done
using the email proposal, but the proposal lacks directness: another way is to
require a property in every WS Resource that lists the components and put named
elements in the Content. This could be done via a profile extension to WSRF .
Meantime, the emailed proposal is encouraging another approach. I like the spec
the way it is, so don’t want to change that.
(TimB) Do we need to provide an answer in AppNotes.
We could simply respond with the idea in the response to the Public Comment.
(IanR) I think we need to back it up with
something in our documents.
(DaveS) I would really like a better way,
but that’s impossible with our current specs.
(IanR) So should we have an imperfect solution
or nothing at all? How imperfect is it?
(DaveS) It will be unfortunate if we encourage
a sub-optimal way to do it: we may end up with two ways to do it
(IanR) Nothing in AppNotes is normative. I
second the motion to accept Tim’s proposal.
(DaveS) Is there anyone besides me who
objects to the proposal as documented being included in AppNotes?
None.
Action: (Bryan) Move to resolved
(DaveS) So AppNotes, Primer and RMD review is outstanding
for next time. But now we have no unresolved issues.
Straggler Roll Call
Closed 13:33
Summary of actions
(Spec Editors) Review AppNotes and send comments to the
list. Carried fwd from 14th Nov.
(Jem/Ian) Review Primer and send comments to the list. Carried
fwd from 14th Nov.
(Bryan/DaveS) Review updated RMD. Carried fwd from 14th
Nov.
(TimB) Make updates to Primer regarding definitions of
resource/WS Resource
(Bryan) Move issues 158, 159, 160, 161 to resolved
(BryanM) Move issue 162 to resolved
(Bryan) Move issue 163 to Resolved
(Bryan) Move issue 118 to Resolved
(Bryan) Move issue 154 to resolved