wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] Draft 04, #3: suggested editorial change
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp@lists.oasis-open.org
- Date: Tue, 21 Dec 2004 11:43:20 -0500
I disagree with #3 as from the Consumer's
perspective, the Lifetime structure is defining when the Producer has scheduled
a destruction for the resource. Whether or not that is carried out at the
scheduled time or results in a reversible change is Producer choice.
Rich
Rich Thompson/Watson/IBM@IBMUS
12/21/2004 11:38 AM
|
To
| wsrp@lists.oasis-open.org
|
cc
|
|
Subject
| [wsrp] Draft 04: suggested
editorial changes |
|
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]