Notes from the OASIS
WSRF TC Teleconference
June 14th 2004
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=4796
Approval of minutes from previous meeting
See: http://www.oasis-open.org/apps/org/workgroup/wsrf/download.php/7130/
There were no comments on the minutes and no objections to
approving them.
Review of action items:
§
(BrianM) Close resolved issues. Done
§
(BrianM) Reword issue 47. Done
§
(BrianM) Email for clarification of issue 48
(Behaviour for nillable properties)
Done. A clarification is anticipated from Sam Meder.
§
(DaveS) Put covering text on the web site for new
drafts
Agreed by email: status is in the documents themselves.
§
(Editors) Update specs to June namespace name
Drafts are published.
ACTION: Votes required by the end of the week (EOD 18th
June)
§
(Editors) Various changes to drafts, including
references to web site
Done - drafts are posted.
§
(All) Review drafts ready for approval by June 14th.
Done
§
(Ian R) to send list of members to the editors. Done
Acceptance of New Issues
No New Issues received.
Resolution
of First group of issues
Issue 6 (Describe properties consistently).
Owner: BryanM
Summary: Description of ResourceProperties should be pseudo-schema
or actual schema.
Resolution: Resource Lifetime to change to use pseudo like
the other standards.
Q (Anish): Do we explain notational conventions in
the introduction – we need to be clear .
A(SteveG) There is a reference to the notaional of
WS-Security.
Q (Jeff) Can’t we be self-contained and include the
notation rather than referencing it?
A(SteveG) There is an inline explanation. – Take a
look and post to the list if it’s not good.
Proposed (DaveS) a new issue will describe the need
for description of notation –
Action:Jeff
The Recommendation is accepted: Proposed (Ian), Seconded
(DaveS)
Action: (Brian) Change status to “resolved”
Issue 15 (Example for MaxOccurs>1)
Owner: SteveG for SteveT
Action: SteveG to send a sample property
maxoccurs>1 to the mailing list for consideration.
Issue 16 (Add query expression dialect to help clients)
Owner: BryanM/IanR
Proposed recommendation: there should be a resource property
exposing the supported dialect.
Action: Bryan/Ian to formulate the property.
Issue 48 (Behaviour of nillable properties)
Owner: Sam Meder for Jarek Gawor
Action: Sam to clarify and propose resolution
Second group of issues (impact to WS-RP)
Issues 21 & 23 (Factoring of set/inquire operations)
Owners: Glen & William respectively.
Action: William to write proposed recommendation to
combining the ops for issue 23.
Action. (Bryan) Remove cross reference to issue 32
(which has been closed)
Q(DaveS) The asymmetry between inquire/ & set
looks strange. What’s the history?
A(SteveG) Set allows mini-scripting approach to update/insert/delete
for systems management properties. The get side was a get-multiple using xpath,
but xpath was too complex a requirement for everyone. Even get qname multiple
was too complicated. Get single is simple.
Q(DaveS) What would we lose by having a simple set?
Q(SteveG) Do you mean we add something or replace
what’s there?
Q(William) Do we need the mini-scripting?
Proposed (Dave/Ian) Don’t combine the operations, but
add options to update to allow simple mechanisms for create/update/delete.
Q(William) How are issue 21 and 23 related?
A(SteveG) If we wanted symmetry, we’d have dialect
for set/update/delete.
Proposed (Ian) Glen was the advocate, so should put
forward an expanded the proposal for 21, and this should to be treated
separately from 23. This proposal should spell out the operations and why the
operations should be split.
(SteveG) We need to justify the split in 23, Glen (and
others) may respond via the mailing list.
Action: (SteveG) Write proposal to resolve issue 23.
Q(Savas) Multiple ops is a way to do scripting, but
when does this become a workflow?
A(SteveG) More complicated scripting exceeds the
powers of setResourceProperty: that’s why insert/update/delete are specified.
Q (Savas) and what about the atomicity of multiple
updates?
A(SteveG) There are sections (5.3 and 7) of the spec
that deals with atomicity semantics (order of requests, etc).
Proposed (Ian) Savas review the spec and come back via
the mailing list if there is something lacking.
Issue 9 (API to list properties)
Owner: SteveG/Bryan
Summary: (SteveG) The problem is that not all resourceProperties
are described in the schema – there could be an “xsd:any”, so we need a dynamic
query to find the currently available properties
There are couple of ways to go. Operation to list resourceproperties
names, or have a resourceProperty called ‘ResourcePropertyNames’.
Q(Savas) Or an operation to get the new schema?
A(SteveG) That’s getting close to the WS_Metedata
function, and it seems complex for a client to replace an existing schema.
(William) We need to also determine the type of the new
property, which might need the imported namespace of the new element.
(DaveS )The common usage might be to select from a limited
range of types, dependent on service instance, or resolved dynamically.
Q(Fred) Couldn’t we have a ?(schema for the
fragment)?
A(DaveS) Anything short of full schema will leave
holes.
(SteveG) could suggest schemalocation be always provided.
QWilliam)how to specify the cardinality of the new
property? We need for a client to be able to get the schema document, or have a
dialect saying ‘qnames’ or ‘xml schema.’ to escribe the document. – this is
based on the operation approach’ to the interface.
Q(Fred) Do we need to worry that the schema is not a
real schema but a collection of fragments describing each element, unordered.
A(William) but the schema could be assembled.
Q(TimB) There needs to be a way to get the schema,
but that’s different from issue 9.
A(SteveG) It’s described by issue 27.
Proposed (Ian) We need a summary of options to be produced by Steve.
Q(Savas) Why not allow extension without xsd:any?
A(SteveG) Validatability is not defined if extensions
can happen anywhere.
Action: SteveG.
Any Other Business
Q(Latha) Is there timeframe for inclusion of issue
resolutions in the drafts?
A(Ian) No there isn’t one until we have a schedule
for publication of new drafts.
Q(?) What about the problem that cell phones can’t
use the toll-free number.
A(Ian) Will investigate more options for
connectivity.
Q(?) can we ratify the f2f details
A(Ian) Need to add this to the TC calendar
Confirmation of next call
Next call is June 28th 12:00pm to 1:30pm Eastern Time
Meeting closed 13:30 EDT.
Summary of Action Items:
§
(ALL) Ballot for working drafts closes 18th
July. Please review and ballot.
§
(Brian) Change status of issue 6 to “resolved”
§
(Jeff) Raise new issue to describe the need for
description of notation.
§
(SteveG) Send a sample property to illustrate
maxoccurs>1 (ref Issue 15) to the mailing list for consideration.
§
(Bryan/Ian) Formulate the proposal for Issue 16 and
publish to mailing list.
§
(SamM) Clarify Issue 48 and propose resolution via
mailing list.
§
(William) Write proposed recommendation to
combining the ops for Issue 23.
§
(Bryan) Remove cross reference from Issue 21
to issue 32 (which has been closed)
§
(GlenDaniels) Write and publish an expanded the
proposal for Issue 21 (treating this separately from Issue 23). This proposal
should spell out the operations and why they should be split.
§
(SteveG) Re issue 23 - write a justification for
the status quo (of split operations for query) and publish to mailing list.
§
(SteveG) Provide a summary of options to resolve
issue 9.
§
(Ian) Investigate a non-toll-free number for US
access.
§
(Ian) Add F2F details to TC calendar.