OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interfaces message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Groups - Interfaces concall modified



Interfaces concall has been modified by Mr Michael Freedman

Date:  Thursday, 24 August 2006
Time:  11:00am - 12:30pm ET

Event Description:
1-888-967-2253 or +44 118 924 9000 (Europe)
meeting ID: 345337
passcode: 060606

Agenda:
1) Discuss using events to manage navState/lifecyle when getResource is involved.

Minutes:
Proposed resolution:
Define a single event the consumer can send to the producer to indicate that a NavigationalState scope transition is occuring.  All other potential features such as sending an event to form a bookmarkableURL or providing for more efficient control via producer setting a dirty falg should/can be considered as extensions/3.0.

Open issues:
1) We have a preference of providing some guidanace (a basic definition of) NavigationalState scope to encourage implementations beyond the null policy but couldn't express something consisely.  Is there a consise definition?
2) What is the name of the event?  In choosing the name we will have to make sure to define the meaning of returning navigationalContext from the HE that receives this event makes sense.


Highlights of the discussion:
1) The group is still split on whether its appropriate for us to address these problems.  A representative group thinks that getResource shouldn't change NavContext in a way that results in the need for a new reference.  I.e. they should only manage (at best) deltas.
2) There are strong opinions that we shouldn't have overally strong conformance statements (i.e. ensure more standard consumer behavior which the producer can count on).
3) Giving the producer an opportunity to migrate any navState managed by reference into the navState itself (by value) may be useful but seems secondary to the problem we are trying to address.  We feel its somethign that can be separated and potentially added independently (as an extension).
4) The two opinions that were expressed concerning naming the event was for wsrp-removeNavigationalContext(Delta).  A consequence of choosing this name is that the consumer would be instructed to ignore/discard any navContext returned by the HE that received this event.

View event details:
http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/event.php?event_id=12419

PLEASE NOTE:  If the above link does not work for you, your email
application may be breaking the link into two pieces.  You may be able to
copy and paste the entire link address into the address field of your web
browser.

BEGIN:VCALENDAR
METHOD:PUBLISH
VERSION:2.0
PRODID:-//Kavi Corporation//NONSGML Kavi Groups//EN
X-WR-CALNAME:My Calendar
BEGIN:VEVENT
CATEGORIES:MEETING
STATUS:TENTATIVE
DTSTAMP:20060824T000000Z
DTSTART:20060824T150000Z
DTEND:20060824T163000Z
SEQUENCE:4
SUMMARY:Interfaces concall
DESCRIPTION:1-888-967-2253 or +44 118 924 9000 (Europe)\nmeeting ID:
  345337\npasscode: 060606\n\nGroup: WSRP Interfaces SC\nCreator: Rich
  Thompson
URL:http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/event.php?event_id=12419
UID:http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/event.php?event_id=12419
END:VEVENT
END:VCALENDAR


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]