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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

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


Subject: Draft 17 comments


  1. Section 5.1.13 -- update wording to expand reference beyond PropertyDescriptions (i.e. EventDescriptions, etc).
  2. If we keep sessionProperties shoudl one only be able to get their descriptions via getPortletPropertyDescriptions ala persistent properties?  Or should persistent properties be gettable in the PortletDescription (for consistency)?
  3. Can you walk me through the rationale, again, for moving ModelTypes down into EventDescription and ExtensionDescription?  I don't understand why ModelTypes moved into EventDescription and ExtensionDescription but not PropertyDescription?  In the end should we move type, schemaLocation, and ModelTypes into a new structure called TypeDescription -- containing both the name of the type and the structure of that type?
  4. Should navigationalParameterDescriptions and sessionPropertyDescriptions follow the same pattern as events (as these are coordination things)?  Namely, the descriptions are supplied at the producer level (ServiceDescription) while th portlet level (PortletDescription) identifies which is used?  Because of how we changed ParameterDescription I don't think this can be done (the non-unique (across portlets) idenitfier field is the only required field).  But could be done for session properties (if we keep them).
  5. Section 5.1.16: fix up descriptions of publishedEvents and handledEvents as they still reference usage of "*" wildcarding.  (You were just testing us, right?)
  6.  Section 5.1.21: Are we only expecting to be able to identify extensions of wsrp types?  I.e. Should the type name be "wsrp:Contact" vs. "Contact" in the example?
  7. Section 6.1.1: Curently says:
    If the Producer returns an InvalidSession fault message after returning a sessionID, the Consumer MUST NOT resupply that sessionID on a subsequent invocation and SHOULD reinvoke the operation that caused the fault message without any sessionID and supply any data that may have been stored in the session.
    Do we want to reword this if we keep sessionProperties to be more specific?
  8. Section 6.1.13: Currently says:
    navigationalContext: This field contains the navigational state for this Portlet. To exist, navigational state must be set explicitly on each URL activation or by setting its value upon return from the performBlockingInteraction or handleEvents operations [C403].
    This statement is no longer true it can also be set(up) by the consumer.
  9. Section 6.1.19: Currently says:
    redirectURL: As a result of processing this interaction, the Portlet may indicate to the Consumer that it would like the End-User to view a different URL. It is mutually exclusive with the updateResponse field. Note that for this version of the specification, these URLs are required to be absolute URLs, however, they are allowed to include portlet URL parameters as defined in [Section 10.2.1] and Consumers MUST rewrite these URLs in the same manner as those contained within markup the Portlet might return.
    Do we mean that the string may begin with wsrp_rewrite (i.e. it will look like a well formed resource URL) or that somehow some of the portlet URL parameters will appear in the string that otherwise looks like a regular URL?


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