Notes from the OASIS WSRF TC Teleconference
						11th July 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=7740

Scribe
John Fuller
Approve minutes of 27th July 2005
Dave S:
See WSRF TC [27June05] notes[1].pdf
   A minutes correction is required because quorum happened late, within five minutes
   of call.  There is an action for Tim Banks to point out quorum was obtained for the 27th
   The TC agreed to modify and approve the minutes.

   (IR, subsequent to end of meeting) The above minutes do actually record, during new issues:    
   “[New attendees means the meeting is now quorate.]” 
   So there is no action required to amend the previous minutes.

Action Review
   All actions for Tom and Brian are to be carried forward since they weren't on
   the call.

(TomM) Post revised draft of specification. Carried Fwd from June 27th
   Not on call.
(Bryan) Remove issue 117 (replaced by 123).
   Not on call.
(Bryan) Move issue 118 to open.
(Bryan) Remove issue 121.
(Bryan) Move issue 122 to closed, no action.
(Bryan) Move issue 123 to open.
(Bryan) Reopen issue 110.
(Bryan) Move issue 110 to resolved.
(TomM) Write new text for resolution to issue wsrf 118. (cut/copy/paste for RMD to go in AppNotes.)
(Bryan) Move issue 119 to resolved.
(Bryan) Move issue 120 to resolved.
_
New issues
There was the potential new issue: the schema location/addressing question from June 30th.  
See http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200506/msg00067.html
There is a trailing slash in our addressing reference which shouldn't make a difference for importing, but say schema A and B both import and use a different slash notation: some validators would treat the imports as distinct.  Ian proposed we change our schema to avoid trailing slash.  The w3c webserver resolves both, but wsn implementers found the technical issue.

(Dave S) Any objections to opening this as a new issue?
No Objections
(Dave S) Do we have a motion to resolve?
<discussion>
       Ian suggested we remove the trailing slash.
	We are out for public review now so any internal issues need to be
	resolved in the same time frame as public comment fixes.
	Even when we finish it, we'll end up changing the url anyway eventually
      Dave S: public comments and internal issues to be fixed in next draft
	report to be published with new draft showing all the changes
      substantive changes require another review
      motion on resolution to remove the trailing slash
      Umit seconded, no TC objections
      martin: to be tabbed as something raised during public review
      martin: difference between internal and public comments?
      ian: internal process can be used by tc members, only an external report
         for those that come through the public comment list
      dave s: tc resolved to allow both processes, track all issues
      tom rutt: agreement internally, could be public w/agreement
      ian: internal process is faster than public review
         report can choose to report only the public comments
         no reason for internal issues because minuted anyway
      umit: issue in public comment from companies?
      dave: both channels are open for tc members
       ian: We have discussed this process as a TC before and resolved as a TC to continue 
      with our internal process for issues raised within the TC; 
	http://www.oasis-open.org/committees/download.php/13291/
       ian: issues list maintained by Bryan will have issues raised through public comment
          annotated as such – as suggested previously in 
	http://lists.oasis-open.org/archives/wsrf/200506/msg00045.html
       tom rutt: minor changes don't need a new public review
</discussion>

In summary, the group agreed to remove the trailing slash for the next round.
Action: Bryan to record this as a new issue in the IssuesList with a state of “resolved” as described above.

_
Issue Review 

WSRF118: How do you cut/copy/paste portions of metadata
   Tom will suggest a resolution and work with the app. note editors per Action carried over from last meeting.

WSRF123: Need a facility to handle collections of ResourceProperties
   Tim proposed.

<discussion>
   Ian: Primer scenario suggested that a collection of RP doc elements (i.e where a RP element with minOccurs greater than a certain threshold) is problematic. The issue text considered 
   revisiting set/update resource properties exchanges
   instead of replacing every member and also considered a change to ServiceGroups to make member-service EPR an optional element of ServiceGroupEntry, for example
      where the shopping cart is a service group and items are entries
      with out actually having members associated with them.
    more appropriate not to break the service group architecture
      which suggests there should be a member for each entry.
      Tim is working on a new draft of the Primer that will illustrate how to resolve this issue without 
      requiring the proposed change to ServiceGroups. The updated Primer will also include a simple 
      scenario that does raise the issue at all, and a third scenario that illustrates appropriate usage of  
      ServiceGroups, including the use of member services. If the primer no longer motivates the
      issue, consider simplifying service groups, but this is something
      Tom should probably be involved with
    dave: not comfortable with breaking the architecture of service groups
       service groups shouldn't just be data elements
       misrepresents the purpose for service groups
       enumeration or simpler data structure would be better
       take another look at primer examples
    ian: Tim should finish work on the primer and distribute to the group
    william: issue of whether or not member is optional may be useful anyway
       for example firewall/discovery issues
    dave:  resolution should not use shopping cart example as-is to motivate ServiceGroup 
    william: service group outside firewall providing access to services
       that can not be addressed directly may be useful
    dave: discuss optionality now independently of the primer?
       at the moment it is a single issue
    ian: same opinion as dave, don't resolve without Tom
    william: we agree about the primer, and should change the issue to be
       about whether the member EPR is optional
    ian/dave agree
    ian: tim to redistribute the primer document, tc to decide on issue
    william to post the use case to the list
</discussion>
_
Public comment archive issue

   Ian noticed it appeared as though none of the buttons work for public review comments work and so public comments are either silently failing of else there is a very long lag time. The problem has been reported to OASIS.

Meeting adjourned, 13:00 EST

Summary of actions

(TomM) Post revised draft of RMD specification. Carried Fwd from June 27th. 
(Bryan) Remove issue 117 (replaced by 123). Carried Fwd from June 27th. (Bryan) Move issue 118 to open. Carried Fwd from June 27th. (Bryan) Remove issue 121. Carried Fwd from June 27th. (Bryan) Move issue 122 to closed, no action.  Carried Fwd from June 27th. (Bryan) Move issue 123 to open.  Carried Fwd from June 27th. (Bryan) Reopen issue 110. Carried Fwd from June 27th. (Bryan) Move issue 110 to resolved.  Carried Fwd from June 27th. (TomM) Write new text for resolution to issue wsrf 118. (cut/copy/paste for RMD to go in AppNotes.) Carried Fwd from June 27th. (Bryan) Move issue 119 to resolved.  Carried Fwd from June 27th. (Bryan) Move issue 120 to resolved. Carried Fwd from June 27th.
(Bryan) Create new issue (ws-addr schemaLocation trailing “/”) with a state of “resolved”.
(Tim) Distributed updated primer which removes requirement on issue 123.
(William) Distribute scenario description that motivates issue 123 independent of the primer.