- Section 5.1.13 -- update wording to expand reference beyond
PropertyDescriptions (i.e. EventDescriptions, etc).
- 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)?
- 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?
- 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).
- Section 5.1.16: fix up descriptions of publishedEvents and
handledEvents as they still reference usage of "*" wildcarding. (You
were just testing us, right?)
- 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?
- 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?
- 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.
- 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?
|