1. WSRP F2F Meeting Eleventh face to face meeting April 27 th – 29 th, 2005 New Orleans

2. WSRP Technical Committee2 April 27, 2005 F2F Goals  Resolve those open issues that will make it into v2 and defer the rest

3. WSRP Technical Committee3 April 27, 2005 Agenda - Wednesday, April 27 th 08:00 Coffee 09:00 Welcome, agenda, elect new secretary, changes at OASIS 09:30 Carol Geyer & Andy Moir (OASIS) 10:00 v2 Primer - Subbu 10:30 Break 11:00 Change Requests CR310 – Add doctype related fields?  Define a “well-known extension” CR311 – Use “event driven Consumer application”?  Approved 12:00 Lunch Break

4. WSRP Technical Committee4 April 27, 2005 Agenda - Wednesday, April 27 th 13:00 Change Requests (cont) CR312 – Clarify InvalidSession fault  Approved CR313 – Clarify cookie usage  Validate known implementations would work with this advice CR314 – Change URI references to IRI? (see: http://lists.w3.org/Archives/Public/www-xml-schema- comments/2005AprJun/0000.html)http://lists.w3.org/Archives/Public/www-xml-schema- comments/2005AprJun/0000.html  Refer to IRI and the need to restrict to URIs for interoperability reasons in 3.1.1 15:30 Break 16:00 Versioning issues New namespace for v2 All – check impact of using the extension concept on coding

5. WSRP Technical Committee5 April 27, 2005 Agenda - Thursday, April 28 th 08:00 Coffee 09:00 Forms and Portlets – Mike Add optional containsForms boolean to MarkupContext where semantics of it being missing is that the Producer is not asserting whether or not the markup contains a form? Add usesEnclosingForm boolean to MarkupParams. Default value is false? Add guidance about need for forms to namespace the names of formfields, etc? Mike to consider further and post a proposed solution. 09:45 FAQ – Clinton 10:10 Leveraging XOP/MTOM – Andre Define bindings that simply declare the Producer supports MTOM. 10:30 Break 11:00 Open Issues #21 – Introduce indications of Consumer functionality?  Do not introduce such metadata #28 – Change requiresSecureDistribution to authorizedNonSecureDistribution?  See issue list 12:00 Lunch Break

6. WSRP Technical Committee6 April 27, 2005 Agenda - Thursday, April 28 th 13:00 Open Issues (cont) #33 – Should leasing operations take a userContext?  Add to leasing operations to maintain symmetry with the factory operations #38 – Operation signature style  Change signature style to use parameter names rather than type names #39 – Default value for supportsExportByValue  Provide no default value. #42 – Metadata needed concerning support for leasing?  Unnecessary #35 – Policy changes that impact a registrations' lifetime  See Issue list Make setPortletLifetime into a bulk operation … just increase the PortletContext into an array. (Response needs to include failure reasons, etc) 16:00 Issue #37 – Encourage POP handles be UIDs

7. WSRP Technical Committee7 April 27, 2005  Consumer is redeployed (consider application style Consumer)  Installation allows pointing at a different Producer  How can Consumer reassociate information about Portlets to use with previously cached info? [Issue: There is no Portlet identifier that is invariant across deployments of compatible versions of a Portlet] Add an optional field [ID] to the PortletDescription for carrying such an identifier.

8. WSRP Technical Committee8 April 27, 2005 Agenda - Friday, April 29 th 08:00 Coffee 09:00Security Tech Note – Richard Engaging WSS TC concerning token usage std values – early drafts cross-posted to WSRP would be useful (perhaps even just a summary) Guidance provided to Richard for drafting this Tech Note 09:30PFB Tech Notes – Richard Naming guidelines still in revision, impacts UDDI keynames 10:30 Break 11:00Open Issues (cont) #34 – Why wildcards in publishedEvents? -> close 12:00 Lunch Break 13:00Open Issues (cont) 14:00Other items 15:30 Break 16:00Roadmap

9. WSRP Technical Committee9 April 27, 2005 Other items  Custom user profile items (see: http://www.oasis-open.org/archives/wsrp/200502/msg00020.html)http://www.oasis-open.org/archives/wsrp/200502/msg00020.html Subbu/Richard to develop a full proposal to carry type information  Blocking semantics of handleEvents? Event distribution step must complete before beginning following step Carry changes to 6.4.2.1 to rest of spec  Config mode (see: http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/download.php/9546/Consumer_Defined_Hierarchies.htm)http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/download.php/9546/Consumer_Defined_Hierarchies.htm No objection to adding such an optional mode – Atul to draft definition  Popup windowstate (see: http://www.oasis-open.org/apps/org/workgroup/wsrp/email/archives/200504/msg00042.html)http://www.oasis-open.org/apps/org/workgroup/wsrp/email/archives/200504/msg00042.html Defer  URLs within resources (see: http://www.oasis-open.org/archives/wsrp-interfaces/200503/msg00034.html)http://www.oasis-open.org/archives/wsrp-interfaces/200503/msg00034.html Primer to add a topic for this  Define “renderEvents”? (improve fragment cachability) Is a part of the cache invalidation topic that has been deferred  Others?

10. WSRP Technical Committee10 April 27, 2005 Items Mike F. raised recently  Page 10 Section 1.2.3: Description of Consumer -- I would like to extend/alter our description of the Consumer -- basically move to extend the notion of Consumer to those applications that view Portlets as a [special] type of view component in its toolset. "A Consumer is an application that incorporates, in part or whole, an intermediary function that communicates with presentation-oriented web services (i.e. Producers and the Portlets they host) on behalf of its End-Users. It gathers and aggregates the markup delivered by the Portlets and other view components for presentation to the End- User..." and then leave the rest as is. However when we get down to the next section [1.2.4] it would be better worded as "The main purpose of a Consumer acting as a content intermediary for various Producer/Portlets is the preparation and presentation of aggregated markup to an End-User...." leave the rest as is. Agreed

11. WSRP Technical Committee11 April 27, 2005 Items Mike F. raised recently  Interface organization: 1. I don't understand the logic for separating the Lifetime interfaces from their natural interfaces. Perhaps if the natural interface were Lifetime independent -- but its not. -- fewer ports/interfaces would be better. Merge back in 2. Does anyone [Consumer or Producer] use the PortletManagement Property interface? This seems like it was a mistake. Even if not it seems of least importance in PortletManagement Interface. Can we move these methods to a new interface? Can we talk about deprecating them in the future? Should be part of a larger refactoring discussion for v3 Note: This feature does need additional work to solve the original use cases 3. Let's move CopyPortlet and ImportExport back into the PortletManagement Interface. PM is already an optional interface -- CopyPortlets/Import/Export are significantly more important to real consumer/producer portlet management then the property stuff ever was -- this will strongly encourage their implementation/support. If we do this merely add UnsupportedOperation Fault which can be thrown to signify lack of support/implementation. Pros and cons both ways … Merge back into PM interface Add features field to SD … define some feature names (events, copyPortlets, etc)

12. WSRP Technical Committee12 April 27, 2005 Items Mike F. raised recently  Types for Event payloads, public parameters, and registration xxxx: We should have/use wording similar to extensions: "The use of types defined within the WSRP extra namespace is encouraged as this increases the likelihood of the Consumer being able to serialize/deserialize the data in a useful manner. Define an additional field within the wsdl for carrying a NamedStringArray form much like was done for the Property type.  Section 5.1.11: EventTypeDescription: Does requiresSecureDistribution really mean requiresSecureTransport -- i.e. only that a secure transport mechanism must be used -- but not other security required? I assume so, however I wonder if we need to adjust these names as it may be somwhat confusing in the future when security is better supported. Field removed

13. WSRP Technical Committee13 April 27, 2005 Items Mike F. raised recently  Section 5.1.12: Should publicParameterDescriptions be of type ModelDescription not PropertyDescription[]? If so need to move this type forward. Agreed  Section 5.2: lines starting at 43. Do the portletHandles have to reference POPs or can they reference cloned portlets? I prefer POPs -- if so need to restrict this in the language. Agreed … CCP handles may be ignored  Section 6.1.18: HandleEventsFailed type: Should detail field really be an any? Better to make a string and leave the any for the extensions? Delete in favor of the extensions field Make xxFailed types consistent with each other

14. WSRP Technical Committee14 April 27, 2005 Items Mike F. raised recently  Section 6.1.19: handleEventsResponseType: Why does an event response return a redirect? How does this impact event processing? Remove redirectURL, note that newWindowState will likely not be honored by some Consumers due to the impact on the overall page’s layout. Subbu to detail a use case for keeping redirect on a similar basis to newWindowState in an email.  Naming inconsistency between copyPortlets and Import/Export: CopyPortlet returns copySuccess/copyFailure fields with correpondingly named types. Import/Export returns imported/exportedPortlets;importFailure/exportFailure with corresponding types. We should reconcile. Change copySuccess to copiedPortlets. Pass current draft by Mike for further comments.

15. WSRP Technical Committee15 April 27, 2005 Items Mike F. raised recently  The description for wsrp-urlType = resource is written with an eye towards consumers that don't support calling getResource() -- i.e. use of wsrp-resourceID and the wsrp-preferOperation parameters hint [strongly] for using the method call but don't require it -- however is this really true. Can't the Producer merely set wsrp-url to ""? Or do we strongly discourage producers from doing so. We might need to be more explicit as to our intentions here. Clarify the model that either/both methods may be specified by the portletURL with wsrp-preferOperation providing guidance for the better option when both are specified. State that Consumers need to support both options in order to provide the expected End-User experience. (if there is a conformance statements for getMarkup and http proxy, make this equivalent)

16. WSRP Technical Committee16 April 27, 2005 Items Mike F. raised recently  "While the Consumer MAY invoke handleEvent() multiple times for any one portlet while preparing to gather markup, it MUST NOT invoke handleEvent() an additional time while the portlet is already processing an event for the same End-User." This implies the consumer can't implicitly timeout an event call without dropping subsequent events from being distributed. Is this what we want? (sections 3.11 & 6.4.2.1) This text was dropped as part of earlier discussion

17. WSRP Technical Committee17 April 27, 2005 Others items raised  Portlets indicating static resources that need to be included in the head of each page incorporating the Portlet. (Subbu) Is part of the deferred Consumer Resources issue

18. WSRP Technical Committee18 April 27, 2005 Deferred items  Asynchronous notifications (leverage WSN?) Add a spec defined event for MetadataChanged  The portlet impacting other places on the page  Consumer resources Example 1: elements, menu items, etc Example 2: services available for portlet usage (e.g. )  Nested scripting  Additional query args on a render url (see: http://www.oasis- open.org/apps/org/workgroup/wsrp/email/archives/200504/msg00048.html)http://www.oasis- open.org/apps/org/workgroup/wsrp/email/archives/200504/msg00048.html  Portlet URLs to other portlets  Non-blocking performInteraction operation  Event subscription (if experience warrants it)  Portlet hierarchies  Cache invalidation  Portlets as WSRF resources  others?

19. WSRP Technical Committee19 April 27, 2005 Teleconference calendar  Wednesday 8 PT / 11 ET / 5 CET – Primer, Conformance, Interoperability, WSDL (as needed, Primer = 5/18)  Thursday 8 PT / 11 ET / 5 CET – TC (5/19, 6/16) 8 PT / 11 ET / 5 CET – Interfaces SC (as needed, 5/5 & 12)

20. WSRP Technical Committee20 April 27, 2005 WSRP Target Timeline  4/27-29/2005F2F (New Orleans?)  6/20/2005 WSRP v2.0 at Committee draft  8/31/2005 WSRP v2.0 public review ends  9/15/2005 WSRP v2.0 submitted to OASIS  10/4-7/2005F2F (Europe) Discuss v3 use cases Host? [Citrix in Dublin?, Sun in Prague]  10/30/2005 WSRP v2.0 => OASIS standard