wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: [wsrp] Draft 04: suggested editorial changes
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp@lists.oasis-open.org
- Date: Tue, 21 Dec 2004 11:38:57 -0500
1. Now that PortletDescription references
PropertyDescription, move PortletDescription definition to after PropertyDescription
definition.
2. Various places (e.g. WSDM) distinguish
immutable (i.e. unchanging) from non-modifiable (i.e. read-only). Current
language states later but uses 'immutable'.
3. The name of the fields "scheduledDestruction"
implies too strong of a semantic. Suggestion is to rename them "terminationTime".
4. The advice (section 6.3) in "Consumers
SHOULD supply a value of “*” in the mimeTypes
field of the MarkupParams
structure as the returned object should simply be streamed to the End-User"
has nothing to do with streaming, but is just calling out that the resource
is not being combined with anything. Update to reflect mimeType requested
by End-User, when known, and note that the Consumer should not care about
the mime type as the response is not involved in aggregation.
5. Section 12.2.1.1.3.1
could be more explicit about wsrp-url carrying the value that gets passed
back in resourceID.
6. In "The value of the wsrp-url
parameter becomes the resourceID supplied to the portlet and, in the case
of http transport, the GET and POST verbs are processed the same as for
performBlockingInteraction", from section 12.2.1.1.3.2, the
last phrase adds nothing as the relevant text is already replicated between
6.1.19 and 6.1.20.
7. With the addition of "capabilities" to PropertyDescription,
publicParameters need to be restricted to writable and optional.
8. Clarify the units for the refreshDuration
field in the Lifetime structure (type=xsd:duration ... tooling now supporting
this?).
9. With the addition of a Lifetime structure,
it would be good to separate the response structures from the request structures
for RegistrationContext and PortletContext.
10. Cache control
wording changes -- how about: "If the cacheControl field is not supplied,
the Portlet is indicating it does not consider the markup cacheable. This
is without prejudice to consumer specific caching policies."
... likewise elsewhere
11. Conformance statement about not
reinvoking handleEvent when one is in progress for the user needs to be
relaxed to allow for timeouts.
If you object to one of these proposed
changes, please update the subject to indicate which so that we get unique
email threads (I will do this for #3 in a couple of minutes).
Rich
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]