Notes from the OASIS WSRF TC Face-to-Face
meeting
13th June 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=7738
Confirm minute taker
Tim Banks is taking the minutes.
Approve of minutes of May 16th
Face-to-Face
See: http://www.oasis-open.org/committees/download.php/13043
There were comments and no objections
Call for AOB
(DaveS) We need 10 mins at the end to talk
about the membership process.
(IanR) Yes.
Action Review
(Editors) Produce PR versions of specs.
(SamM) Basefaults still outstanding – will
be done sometime this week.
Actions:
(Sam) to post PR version Basefaults
(Ian)
Contact OASIS to start review. Done
(DaveS) If we get this done we should be in
good time to get public comments by the next face-to-face.
(TomM)
Distribute updated RMD spec Done
(Tim) Iterate Primer following 6 June discussion. See below.
(Steve G) Raise new issue for further relaxation of RPDoc constraints. (SteveG)
the issues is to remove constraints on the RP documents, broadening to ‘Legacy xsd’.
(SteveG) The issue is whether we can
simplify the constraints on RP Documents so that we can incorporate legacy xml
documents. I need to review and post something. Carry fwd.
New
issues to consider - Chair
wsrf-rp review comments - typos in WSRF-RP
(IanR) Hideharu found these: I posted them
to the list: http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200506/msg00017.html
(DaveS) These are already fixed aren’t
they?
(SteveG) Yes.
(DaveS) There is one potential new issue:
Modeling Potential Service Groups
(DaveS) This resulted from last week’s
discussion of the Primer example and how print jobs should be modeled. The entire
thread is here: http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200506/msg00013.html
(TimB) The discussion last week proposed four ways to update provide updated
access to repeated child elements in an RP document, eg of jobs in a print
queue, where the status of one of the jobs is to be changed.
- Use explicit id. Eg use a ‘cancelJob’
operation on the printer which explicitly quotes the id. This is against
the grain of WSRF.
- Use the existing mechanisms and replace
the whole collection with a updateResourceProperties. This becomes hard
if the collection is large.
- As a Servicegroup with jobs as member
Services an abstract of the Job in the ServiceGroup Entry. This seems
unnatural.
- As a Servicegroup with null ServiceGroup
Entry, and all information in the MemberService. This also seems
unnatural.
The issue is whether we need a new
mechanism to manage collections of by-value child elements.
(DaveS) This would be more sophisticated
than the current method of updating the whole collection, so we would subset
the collection. Did we have anything like this in OGSI days?
(SteveG) No. What we have reflects we had
for ServiceData.
(DaveS) This starts to get to a more
complicated vision in which properties have several distinguishing
characteristics; they have their name and some other attribute which allows
them to be distinguished from each other when performing an update. Would this
be an extension to ResourceProperties, or can we do this with ServiceGroups?
(TimB) I don’t think Sg is the right way.
We could leave it to the application to define each Child element as a
WS-Resource. In effect a simplification of ServiceGroup which allows a null
member service. I’m not sure whether we should make this change to SG.
(DaveS) This would be where the Entry holds
all the information, and the EntryEPR would allow manipulation, but without a memberService
beyond it. Would the lifetime operations be usable?
(TimB) The Entry is a WS-Resource, so we
shouldn’t make a special restriction.
(IanR) In the case of Print Job, canceling
a printJob would be affected by sending Destroy message.
(TimB) Yes – you could use Destroy as the
cancel.
(IanR) Dave, when you said ‘Entry’, was
that in the context of SG?
(DaveS) This would allow a SG Entry to not
contain a pointer to the memberService. Yes?
(TimB) Yes.
(DaveS) so in some ways it’s a very simple
change to the SG spec, but with enormous semantic implicatations because the
member may not exist as a separately addressable entity.
(TimB) So there are two proposals: leave it
to the applications to model child elements as WS-Resource when they are too
numerous for UpdateResourceProperties, or make the memberServiceEPR in SG
optional.
(DaveS) Is the pointer required at the
moment?
(TomM) I need to look, but perhaps we can
relax this, if we said the collection is unconstrained wrt interfaces of member
EPRs.
(DaveS) Yes, we don’t want to not support
interfaces because the EPR is null.
(TimB) So we wouldn’t have a membershipContentRule?
(TomM) The rule can also describe Content.
(DaveS) But these aren’t required to be resourceProperties,
it could be other content. Which seems appropriate. If there are no objections,
I would say this is a new issue.
(IanR) Can we restate what the issue is?
(Umit) Yes, please!
(TimB) It’s about a more appropriate way to
manage WS Reousrce with repeated child elements which need to be updated.
(DaveS) The shopping cart with a list of
items is the simplest example, where I need to change one item, but currently
we need to change all of them.
(IanR) That has always been so.
(DaveS) Indeed, if we were only to use ResourceProperties
to do it. Another way to do it is to model the items as a collection of member
Services in a SG. This seems a bit heavyweight. So this idea is proposing to
open a middle ground in between so that we can talk about a member of a
collection, in this case a serviceGroup entry, but without the member Service.
(IanR) The SG entry has exactly one
associated member, and the proposal is to have a cardinality of zero or one.
(DaveS) There are semantic changes
associated with that.
(IanR) So if the SG Entry had no member, it
could still have content.
(Umit) What is the requirement for content
if there is no member service?
(TomM) The content is derived from the SG
implementation, or derived from the Add. It might or might not come from the
member service. Also we added an optional RP document sub-element which means
the content is a cache copy of the RP document of the member.
(DaveS) That’s optional, yes?
(TomM) Right, and that would be precluded
by this suggestion.
(Umit) Right.
(William) Why? You could have a member
that’s not reachable.
(TomM) I don’t think we can talk about that
normatively.
(Umit) I agree, we don’t know what it would
be referring to.
(TomM) We could still have it..
(DaveS) But without a member EPR we can’t
cache the document.
(William) Yes, we could. It could be
something that isn’t obvious, but it could be done internally, without the EPR,
and still be part of the semantics of the data.
(DaveS) So, that’s enough discussion to
make it an issue. It would be for a revision after the public comment period.
We can raise it internally, or make it public which would make it quicker to
turn around.
(TomR) Either way works, as long as we
publish a document with resolutions including internal and external comments.
(IanR) I don’t see why we need to change
the process we’ve got.
(DaveS) Ok, so we need a detailed change
list with the revised text. Tim should raise an issue.
(IanR) Can we resummarise the issue one
more time?
(Tim) I think it’s that we need a way to
deal with update of a by-value collection.
(IanR) Absolutely, but we have this already
via SetResourceProperties and UpdateResourceProperties.
(William) We could describe it as making
the memberServivceEPR optional.
(TimB) This points to a resolution which is
Ok with me.
(DaveS) We need more information to justify
this, to say that update individually or by subset is required, compared to
updating all.
(IanR) Well, this is either an issue with ResourceProperties,
or with ServiceGroup.
(William) I think it’s with SG because
there may be additional use cases that we want to consider.
(SteveG) Yes, I think it’s with SG. We also
need to consider the implication on Membership control.
(TimB) So the issue is on SG and whether we
make the Member ServiceEPR optional.
(DaveS) I think we should describe it as a
gap in the capabilities of the whole WSRF framework. The proposed resolution of
which is a change to SG, because we might find another resolution.
Action:
(Tim) Post description to the list.
Action: (Bryan) Raise this as an open issue.
(TomR) We could have these new issues in a
different document, so that voters can vote on the resolution of issues raised
during the review.
(IanR) My preference would be to carry on
managing internal issues as they are at the moment, then merge their
descriptions and resolutions with public review issues at the end.
(DaveS) Yes, we may discover issues that
don’t need to be included. We’ll manage internal issues as normal and create a
new ‘changes’ document at the end of the review period.
(TomR) Or we could make a public comment
when we’ve made a decision within the TC.
(DaveS) I think we’ve concluded we don’t
mind doing the merge at the end because we might not want to include all
resolutions made by the TC.
No Objections.
Final comments before we start Public Review?
(DaveS) Here’s the list of the ones that
have already been dealt with:
From Ian:
-Line 707, 1632, 1634, 1638
It seems to me that "QueryResourceProperty" should be
"QueryResourceProperties" instead.
-Line 1385
I found "DeletResourceProperty". It should be "DeleteResourceProperty"
(or
"DeleteResourceProperties" ?).
-Line 1632
"ResourceChangePropertyValueNotification" is wrong topic name. The
correct
one is "ResourcePropertyValueChangeNotification".
(DaveS) Are there any other comments
(TomR) But we voted already, yes?
(IanR) Right, we should just go with the
documents we voted on.
(IanR) Anyone who has comments should
continue to feed them into the TC.
(DaveS) Ok. Right.
Review
either/both updated RMD - Tom
(TomM) I’m going to be making changes, and
need some guidance. We need to put in some advice about cut/copy/paste, but it
should be in the AppNotes, right?
(IanR) Right, so we need a new issue to describe
the equivalent for metadata.
Action: (TomM)
Raise new issue.
(TomM) Also, we have a ‘definitions’
component which gives a targetnamespace. I’m not sure if we still need this.
Also multiple metadata descriptors allow collection of info about multiple
services. I think we should carry this forward. All that’s left in a
metadata descriptor is multiple property elements.
Do we need extensibility in metadata component,
and if not, is the component useful?
(DaveS) It sounds as though there are
enough pieces to go into that section.
(TomM) It seems like metadata exchange
could be a useful idea, and to restrict ourselves to property metadata and
allow others to deal with operations if they want to. The metadata descriptor
is a container for resource properties. Should it be focused on RP, or more
generic?
(DaveS) I would like what we do to play
well with other proposals that are in progress. I don’t want to make a general
framework.
(TomM) I’ll open an issue and make some
suggestions in which case we don’t need extensibility. Or do we?
(SteveG) Extensibility is the fashion, but
it doesn’t work well with jaxrpc.
(DaveS) So this should be an issue, too.
Action: (TomM)
Raise new issue to discuss the name of the metadata container and extensibility
capability.
Action: (Bryan) Move this issue to open.
(TomM) We also need to say something about
overlapping descriptors in the metadata components. Each of these things needs
to be addressable via qname, which means having GED. I suggest we drop all the
pathing and just have a Qname reference and have open attribute content.
(DaveS) So this is another issue.
Action: (TomM/Bryan)
Write issue proposal for metadata descriptors to refer to GED and have open
attribute content. (Move to open)
(DaveS) Can we get an updated document by
the next call?
(TomM) I can put up a document with
proposed resolutions.
Action: (TomM)
Post updated spec.
Issue review - Chair
(DaveS) There is no time for this.
AOB: Membership process
(IanR) The OASIS administration published
TC process guidelines. The membership status have been changed. Before we had
observer and member, now we have observer, member and voting member. Anyone can
be an Observer without being constrained by IPR considerations, and can’t
contribute (KAVI will be made to prevent this). We have a lot of Observers who
which to contribute and whose organizations have signed the IPR agreements, and
we need to convert these to non-voting members. We intend to contact the
organizational member for all signed-up organizations and ask them if they want
members to be converted. We will seek OASIS assistance to allow the other
members to contribute until the new rules are implemented at the end of the
year.
(SteveG) Does this affect our ability to be
quorate.
(DaveS) No. This only affects
Observers/non-voting members.
(TomR) We need to decide at some stage we
need to check our IPR status.
(DaveS) Hopefully the specs will be
finished before then.
(TomR) Right, but if the TC still exists, it’s
status needs to be resolved.
Straggler Roll Call & Close
Closed 13:00 Eastern time
Next telecon is on June 27th.
Summary of actions
(Sam) To post PR version Basefaults.
(Steve G) Raise new issue for further
relaxation of RPDoc constraints. Carried fwd from 6th june.
(Tim) Post description of new issue to the
list, describing gap in the framework with potential resolution in SG.
(Bryan) Raise this new issue as ‘open’
(TomM) Raise new issue to describe the
equivalent of cut/copy/paste for metadata.
(TomM) Raise new issue to discuss the name
of the metadata container and its extensibility capability beyond RP documents.
(Bryan) Raise this issue as ‘open’.
(TomM/Bryan) Write issue proposal for metadata descriptors to refer to GED and
have open attribute content. (Move to open)
Action: (TomM)
Post revised draft of specification.