WSRP v2 Open Issues Thirteenth face to face meeting May 2 nd – 5 th, 2006 San Francisco

Restrict NavParams types? (Mike) ● Restrict to scalars (include array of scalar types also)? – Approved... restrict to strings, comment – Transfer with QNamedStringArray – New type for description... include a required key for the purpose of keeping URLs shorter – c/key/identifier (5.1.16) – make name optional – Transfer using NamedStringArray ● Change model from a view onto the navState to Consumer stored & supplied? – Yes, add conformance statement requiring Consumers to resupply on future invocations all described parameters for which values have been set – NavigationalState as a structure, opaque and values(?) as fields.

TransientProperties and getMarkup (Mike) ● Allow getMarkup to return transient properties? – Needed if we view transient properties as a remote extension of the Portlet session ● Responses suggested instead explicitly declaring getMarkup to be an idempotent operation... ● Portlets SHOULD consider getMarkup to be an idempotent operation, but since there are use cases for navigational oriented transient properties, it is allowed for transientPropertyUpdates to be returned. (find HTTP's similar language...) – Delay until after JSR286 EG F2F next week?

MTOM and SOAP1.2 bindings? (Rich) ● Add bindings for proposed SOAP v1.2 and MTOM specs? – – ● Delegate to the WSDL SC for dealing with these proposals as they move forward.

Consumer generated event UIs (Stefan) ● Use case: – portlet displays contact information about persons (name, , phone, etc) – other portlets accept such person information as event input parameter – consumer would like to generate a UI, e.g. popup that would allow the user to choose to which other portlet this information should be sent (e.g. the menu can contain things like: add to addressbook, send , call) – after selecting one item of the list the consumer would issue an event to the target portlet ● A similar paradigm is used in the windows explorer with the sendTo popup menu. ● Stefan to write up as a v3 feature (initial pass may already exist)

TransientProperty model (Subbu) ● Interface model like navigation Parameters or Consumer-managed (current transient properties)? ● Discussed options: – Consumer stores, manages and then supplies TPs on each relevant invocation => current spec – Producer also stores TPs and uses an update if changed algorithm to process the TPs the Consumer supplies (i.e. manages side-effects itself). – Producer informs Consumer that it also maintains TPs and the Consumer maintains 'dirty' bits to determine what to send on the next invocation. ● First has the largest message size. ● Second has the same message size as the protocol is not leveraging the fact that the Producer is also maintaining a TP store. ● Third has the smallest message size, but increases the work that the Consumer must do both when processing a new TP value and when building the message for the Portlet.

TransientProperty model (Subbu) ● Discussed options: – Consumer stores, manages and then supplies TPs on each relevant invocation => current spec – Producer also stores TPs and uses an update if changed algorithm to process the TPs the Consumer supplies (i.e. manages side-effects itself). – Producer informs Consumer that it also maintains TPs and the Consumer maintains 'dirty' bits to determine what to send on the next invocation. ● Third has an orthogonal issue regarding optimization; namely: – The protocol could support the Producer informing the Consumer that an optimization can be leveraged, but not require Consumers to take advantage of it. – The protocol could require Consumers support this optimization. – The protocol could require Consumers and Producers support this optimization. ● Leave as is for now, some may implement as an extension.. ● Change to being sessionValues within the SessionContext/RuntimeContext – as an API onto privately stored values?

ExtensionDescription (Rich) ● ExtensionDescription requires name & type with optional aliases, descriptions and locations. ● However, extensions could have different payloads depending on the location being extending. – For example; consider an extension, foo:bar which: ● extends ServiceDescription/RegistrationData with metadata defining whether any optional parts of the foo:bar extension are supported. ● extends one or more request messages with additional information the Consumer will supply to the Producer ● extends one or more response messages with additional information the Producer will supply the Consumer ● Should we move type and locations[] into a new structure which ExtensionDescription then includes as an array? ● Approved

Portlets with Consumer stored portletState? (Stefan) ● Use case: – Portlet returns portletState in order to have this state stored on the Consumer – part of this state contains the server address where the Portlet gets the and calendar information – the Portlet is destroyed and would like to clean up the entries on the server, however, the destroy call does not provide the portletState, but only the portletHandle ● Add language pointing out this issue to Producers ● Conformance language starting 8.4 (also 6.1.3) needs to reference deregister ● Forward references in 3.7

wsrp:consumerSessionScopeDestroyed (Stefan) ● There are use cases where the Portlet would like to receive the current transientProperty values in this event. – Note that the invocation sending this event includes all TPs, same as any other he() invocation (i.e. The notification should be sent prior to the actual ending of the Consumer session).

transientPropertyDescriptions field (Rich) ● Add the following? – An example of when this might not be appropriate is when the Portlets are related to the same Producer offered portlet handle. The context in which the Consumer is using Portlets related to the same Producer offered portletHandle will determine whether or not such Portlets will share the same values for their transientProperties. ● Revisit – Not needed

Multiple types for an EventDescription? (Richard) ● Certain events could be generating different event types depending on portlet state, etc. ● ServiceDescription.eventDescriptions: These descriptions match events at runtime via the event name, with it being an error for the runtime event type to not match the EventDescription declared type. ● Also: This array of EventDescription structures, with unique event names, des...

(Scoped) PropertyDescription (Richard) ● Other metadata structures have a localized description field... why not PropertyDescription & ScopedPropertyDescription? – Add ● Why isn't the usage field a QName? – Leave as is

Schema types (Richard) ● We provide means to include schemas, but not URIs for simply referencing schemas ● Add schemaLocation (type=URI) to appropriate metadata and runtime types. ● Some locations also do not have a means to include inline schemas (EventDescriptions) ● Reword :name (name of the XML element...) ● Can QName localname part have '*' as a character. - NO

navigationParameters (Richard) ● Do Consumers have to track when a value changes or can they simply send values received in this cycle of handling a user interaction regardless of whether the value was already sent to the Portlet on an earlier invocation? ● Depends on the revisit to slide #2 => change in model eliminates this issue

Property type (Richard) ● Other features with types carry it both in metadata and runtime... why not Property as well? ● Add

String or QName? (Richard) ● Why aren't fields like ServiceDescription.supportedFeatures QNames? ● This field provides an extensible means to indicate what optional features/extensions the Producer ● This field uses the string type for maximum flexibility, but it is recommended that QName-like values be used as a means of reducing name collisions. ● Change name to supportedOptions ● Side issue: Do we really need to define all the values currently in the spec?

ExportDescription? (Richard) ● If we moved recommendedExportSize to a new descriptive structure, it would make it easier to add other descriptive fields in the future. ● Do this

scheduledDestruction (Richard) ● Make the last sentence a conformance statement... Consumers MUST NOT send the scheduledDestruction field... ● Elsewhere too... ● Leave as is

Http header fields (Richard) ● Should getResource supply these to the portlet? They may be needed to properly proxy the request to a back-end service. ● Add optional requestVerb field to ClientData ● Should we explicitly recognize the possibility of such Producer proxying? ● Primer issue

Failure reasons (Richard) ● These seem more like faultcodes ● Why define QNames and have the type be string? ● Why are our faultcodes Qnames? – Rename to errorCode (type = Qname (or an enumerated type)) – Optional reason field... no defined values – Make DestroyFailed consistent

get/set mismatch (Richard) ● SetPortletsLifetime can deal with an array, GetPortletLifetime is singular. This mismatch appears odd. ● Make both array oriented, responses become an array of PortletContext/Lifetime pairs with appropriate failure arrays...

Metadata versioning (Richard) ● Would a monotonically increasing number provide a simple means to improve metadata caching? The get operations could supply this so that responses could shortcut if it is current. ● Richard to propose as an extension in the v3 timeframe

Locale definition (Mike) ● We only reference the first two portions of std locale definitions. ● Reference the same RFC as xml:lang

Editorial (Rich) 1.EventPayload: Schema allows multiple any elements, spec does not - done 2.Could some aspect of line numbering be added to the html? [RT: Would likely require an xslt transform] 3.Version the extra namespace? - done 4.Make example in 3.4 explicitly the context of a CCP - done => interactionState is as opaque as navState - done => add handleEvents to the list of operations - done 7.Change navigationParameters to navigationalParameters? - done (publicValues) 8.New navParams are only received on URLs and responses from pbia() and he()... be explicit. - done 9.BNF => true | 1 and false | 0 - done Do all

Editorial (Rich) ● MarkupParams.secureClientCommunication => can Consumers reliably set this flag?? - done ● 3.10 => constituent isare - done ● Need to do a pass relative to additional references to the requirements document ● Do all