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.
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.
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.
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.
Accept as Open.
Issue 38 (Requirements Document)
Accept as Open.
Accept as Open.
Accepted as open � contact is Dave Snelling.
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)
Seems similar to 30
Keep open and add a reference to issue 30.
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.
Proposed 27/28 July, hosted by Fujitsu,UK.
No objections.
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.
Proposed to remove temporary fault structure.� Already addressed in schema, but not in specs.
No Objections.
Spec editors to resolve.
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.
�
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.
Proposed to change the example to something more concrete (eg �streetName�).
..or �ResourceDisambiguator�
No Objections.
Spec editors to resolve.
Resolved to make it so (for the first reissue)
Recommended for one per �SetResourceProperties� component.
One notification message can contain multiple notification elements.
No objections to proposal.
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]