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: Re: [wsrp] Draft 04, #3: suggested editorial change



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]