1. getPortletProperties() is not a QName[]
  2. Cannot subscribe to all events in a namespace
  3. (Proposed) Clearing a parameter's values in public navigational values should override any other setting of the same parameter, either in the UpdateResponse NavigationalContext PublicValues or in the wsrp-navigationalValues URL parameter. Specifically:

    • In the UpdateResponse structure of a PerformBlockingInteractionResponse or HandleEventsResponse, the NavigationalContext publicValues fields allow specification of changes to public values. The specification of a parameter without a value is interpreted as clearing the parameter's values. It should be considered invalid in this structure for a parameter to be specified without a value (indicating the parameter's values should be cleared) while having the same parameter name specified with a value (empty or not) in the same publicValues array, and that the consumer should treat any such specification of a parameter-clearing and parameter-value-defining for the same parameter as simply clearing the parameter values and NOT defining any new values.

    • In the wsrp-navigationalValues URL parameter, as described in section 9.2.1.3 of the WSRP 2.0 spec, there should be a further clarification that clearing a navigational parameter should override any other specification of that parameter's values. The sample given in the specification:
      • p1=value1&p1=value2&p2

        • which defines two values for parameter "p1" and clears all values for parameter "p2" should be expanded to specify that:

        p1=value1&p1=value2&p2&p2=value3

        • is invalid, and that the consumer should treat any specification of a parameter-clearing and parameter-value-defining for the same parameter in a wsrp-navigationalValues URL parameter as simply clearing the parameter values and NOT defining any new values.
  4. (Proposed) The specification in section 4.1.11 of the WSRP 2.0 spec that the event name "also becomes the XML element name carrying the payload with the type field defining the type of the element" should be removed or treated as strictly optional. This statement conflicts with the consumer's ability to rename events for alias-matching and still treat the event payload as opaque if the event payload type is not defined, and also conflicts with the (proposed) extension for defining standard, well-known "simple" event payload types.
  5. Clarification of: 4.1.20 CookieProtocol Type

    1. The spec intentionally does not define what a "user" is, thus it is left up to the consumer to define what a user is and when to call initCookie.
      • Some common definitions of a user include:
        • An authenticated user.
        • A client-consumer session
    2. The consumer MAY or MAY NOT call initCookie when a user authenticates.
    3. A producer SHOULD NOT depend on any particular definition of a "user" and SHOULD NOT rely on the consumer calling initCookie when a user authenticates.
      1. A producer MAY throw an InvalidCookie fault if it cannot proceed.

        1. The consumer MUST automatically handle the fault, per section 5.5 of the WSRP 2.0 Specification.

WSRP_v2_Errata (last edited 2010-02-25 16:32:12 by nathan.lipke)