wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: [wsrp] Change requests for Thursday, March 27th
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp@lists.oasis-open.org
- Date: Wed, 26 Mar 2003 15:05:32 -0500
The change requests (and current email
discussion summaries) for the call are:
#237(b): Alternative for supporting a control set style
=> Discussion of how the Consumer can inform the
Portlet of the controls "normally" in use for the mode/window
state.
#240: Remove Interface.UnsupportedLocale fault
=> Discussion has come down to either we
should:
1. tighten up the semantics around locales
(Consumer MUST select from the set declared as supported through the PortletDescription,
etc.) ... this would keep the fault definition.
2. Leave locales as a prioritized request
and allow the Portlet to return any locale ... this would remove the fault
definition.
#242: Logic of 127 chars recommendation
unclear.
=> Suggestion looks to
add clarity as to why the first 127 characters are recommended.
#243: extensions field description
=> Request breaks the
one sentence description of the extensions field into 2 in order to clearly
state that extensions elements MUST come from a non-wsrp namespace.
#244: Back door to declaring charsets
for MarkupTypes
=> Should the spec comment
on the mime type can include optional declarations such as charset?
#245: UserScope and caching
=> Is a Consumer prohibited
or discouraged from caching content when it does not understand the specified
userScope?
#246: userProfileItemDescriptions
rename
=> Consistency says this
field should be customUserProfileItemsDescriptions
#247: Rename binding wsdl file
=> Noting that for consistency,
this filename should use the plural "bindings".
#248: Section CSS classes
=> Question raised whether
to define a parallel set of classes that are table specific?
#249: Class name length impact
on performance
=> Request by the "performance
police" that the class names be shortened.
#250: Only 1 performBlockingInteraction()
per End-User interaction?
=> What is the harm as
long as the blocking semantics are followed? Also, this conflicts with
the required semantics of receiving back an InvalidSession or InvalidCookie
fault message.
#???: redirectURL mutually exclusive
with interactionResponse
=> discussion thread
(not a formal change request) questioning whether all of the UpdateResponse
structure should be mutually exclusive with redirectURL.
Others that may still arrive .....
Rich Thompson
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]