W SRP F2F Meeting

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

2. F2F Goals • Resolve those open issues that will make it into v2 and defer the rest WSRP Technical Committee

3. Agenda - Wednesday, April 27th 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 WSRP Technical Committee

4. Agenda - Wednesday, April 27th 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) • 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 WSRP Technical Committee

5. Agenda - Thursday, April 28th 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 WSRP Technical Committee

6. Agenda - Thursday, April 28th 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 WSRP Technical Committee

7. 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. WSRP Technical Committee

8. Agenda - Friday, April 29th 08:00 Coffee 09:00 Security 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:30 PFB Tech Notes – Richard • Naming guidelines still in revision, impacts UDDI keynames 10:30 Break 11:00 Open Issues (cont) • #34 – Why wildcards in publishedEvents? -> close 12:00 Lunch Break 13:00 Open Issues (cont) 14:00 Other items 15:30 Break 16:00 Roadmap WSRP Technical Committee

9. Other items • Custom user profile items (see: 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) • 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) • Defer • URLs within resources (see: 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? WSRP Technical Committee

10. 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 WSRP Technical Committee

11. Items Mike F. raised recently • Interface organization: • 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 • 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 • 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) WSRP Technical Committee

12. 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 WSRP Technical Committee

13. 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 WSRP Technical Committee

14. 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. WSRP Technical Committee

15. 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) WSRP Technical Committee

16. 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 WSRP Technical Committee

17. 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 WSRP Technical Committee

18. 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: <head> 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) • Portlet URLs to other portlets • Non-blocking performInteraction operation • Event subscription (if experience warrants it) • Portlet hierarchies • Cache invalidation • Portlets as WSRF resources • others? WSRP Technical Committee

19. 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) WSRP Technical Committee

20. WSRP Target Timeline • 4/27-29/2005 F2F (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/2005 F2F (Europe) • Discuss v3 use cases • Host? [Citrix in Dublin?, Sun in Prague] • 10/30/2005 WSRP v2.0 => OASIS standard WSRP Technical Committee