Notes from the OASIS
WSRF TC Teleconference
May 17th 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=4794
Approval of minutes from previous
meeting
See: http://www.oasis-open.org/apps/org/workgroup/wsrf/download.php/6689/
No objections were raised.
Proposed Charter Clarifications
These were posted to the mail list here:
http://www.oasis-open.org/archives/wsrf/200405/msg00049.html
There were no objections to the loosening of the imperative
to achieve separation.
There were no objections to the inclusion of a requirement
for an explanation of what stateful resources are.
Q (Savas): Can we also have a description of what a
stateless Web Service is?
A (Dave S) it would be presumptuous for this TC to
define this. It is the role of W3C to define this.
(Savas): the charter starts from assumptions, and these
should be made clear by defining “Stateless Web Services.”
A (Ian): this should be part of the specs, and is an
important question, but not part of the Charter.
Q(Savas): In the charter, the term ‘stateless’ is
used. Should this be explained?
A (Dave): We’ll need to define a stateful resource,
which implies the need to define what stateless is. No charter change is
needed.
Q: (?) Could we add a comment about the context
assumed in the words ‘Stateful resource’?
Proposed (Ian)/Seconded (Dave). Adopt the changes proposed
in the email, except that the second revision should read:
This TC will define the means by
which:
Web services can be associated with one or
more stateful resources (named, typed, state components) and what is meant by a
stateful resource and the context in which it operates.
No Abstentions, No Objections and the motion was carried.
Issue-raising process
There were no objections to the process proposed in the
email:
Q(Steve G): Can a list of contents be included
please?
A(Bryan): Yes.
Summary review of new issues
Issue 35
(Schema constructs in
property document).
Needs clarification
A(SteveG) It can be removed, since it is resolved by
section 4.2 of the specification. The description of the complex type needs to
be unambiguous, but it currently is.
Issue 36
(Web Methods Binding).
Needs clarification. It should say that WSDL2 Web Methods
binding must be possible. Can be clarified, and then closed until it appears
that there is a problem with producing such a binding.
Issue 37 (Versions and Compatibility)
Accept as Open.
Issue 38
(Requirements Document)
Accept as Open.
Issue 39
Accept as Open.
Issue 40 (EPR)
Accepted as open – contact is Dave Snelling.
Issue 42 (Alternatives to implied resource pattern)
Anish: Do we need a Resource Pattern vs to explicitly
specifying documents in WSDL which allows typing/discovery/composition.
Q(Ian): Is this distinct from Issue 40?
A(Anish): Yes. EPR only requires a URI, not a
service. The second part is about Reference Properties. 42 is about the
resource pattern itself.
A(DaveS): There are alternatives to the Resource pattern
(people have been using Web Services without it already), but the TC is
chartered to make the Resource Pattern work. Proposed to remove the issue as
out of scope.
Q(Fred): Should we decide beforehand what the specs
will say? Are there sacrosanct sections of the proposals?
A(Ian):Issue 40 is on the table, but the pattern is
what we are about.
Anish: but the pattern means that we don’t specify things in
WSDL. Without additional knowledge, one has no idea that the service implements
WSRF.
SteveG. There is no prohibition to describing it in WSDL, or
as a policy.
(Fred) Should we have an issue to ask what is WSRF?
(Dave S) This issue is a statement that we need to work on
WSRF!
Proposed (Ian) to close the issue in favour of a new issue,
more narrowly focused (eg how properties are declared and discovered).
Seconded (SteveG)
Issue 43: Consider moving to the WS-Addressing 2004 namespace
Seems similar to 30
Keep open and add a reference to issue 30.
Issue 44:
Keep open.
Issue
45: Add Element form default.
Q(SteveG) is this really an issue, it’s a clarification
that’s needed in the next rev of the specs.
Sam: Yes close and move to the appendix of schema changes.
New
Issues 46 and 47 (EPR – WSDL relationship)
Derived from the WSDM TC. Both to be kept open.
Date of next F2F
Proposed 27/28 July, hosted by Fujitsu,UK.
No objections.
Scope of work before republishing 4 spec documents
Proposed to:
-
Use OASIS template and new OASIS logo
-
Namespace - Steve Graham to summarize WS-N approach
-
(ie minimal technical work to allow implementers (eg
WSDM) to use them)
A(Ian): What did the WS-N team do wrt namespaces?
A(SteveG): There is an OASIS standard emerging that
has been already adopted by other TC’s, and a Web site structure that we should
respect.
-
oasais.open.org domain name
-
‘WSRF’ qualifier
-
a date
-
Some other identifier
Please post to mailing list if there are comments.
Issues Discussion
WSRF2: Realign specifications using WS-BaseFaults
Proposed to remove temporary fault structure. Already
addressed in schema, but not in specs.
No Objections.
Spec editors to resolve.
WSRF3: Should get property return fault?
Proposed to return an empty element.
Q(Fred): What if a property is nillable? How can we
represent this?
(Anish): Some language bindings map <nill=true> and
empty element to the same thing.
No objections to closing the original issue, but a new one
is needed.
WSRF4: Get for document with xsd:any
Proposals:
-
Return a fault – fail safe.
-
Return an empty message
(Fred) How is this different from Issue 3, which proposes
returning an empty document.
Unresolved: needs more discussion.
WSRF14: Rename example property name ‘ResourceID’
Proposed to change the example to something more concrete (eg
“streetName”).
..or “ResourceDisambiguator”
No Objections.
Spec editors to resolve.
WSRF31 Make capitalization consistent.
Resolved to make it so (for the first reissue)
WSRF33: Multiple Notifications or one property change?
Recommended for one per ‘SetResourceProperties’ component.
One notification message can contain multiple notification
elements.
No objections to proposal.
Summary
Spec editors to consider 5 issues, proposing updates via
mailing list.
Any further ‘obvious’ issues to be identified to the mailing
list for discussion on inclusion in first refresh.
Closed 18:40