[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [wsrp-wsia] [change request #210] Duplicate conformance statements
Document: Spec Requested by: Rich Thompson Reasoning: Duplicate conformance statements. These changes propose keeping one as a conformance statement and making the other semantic statements instead. ID: A Section: 6 Page/Line: 25/18 Statement to keep: All Producers MUST expose this portType (section 14) Old text: As user-facing, interactive presentation-oriented web services, WSIA or WSRP compliant services MUST implement the markup interface. New text: As user-facing, interactive presentation-oriented web services, all WSIA or WSRP compliant services implement the markup interface. ID: B Section: 6.2.1.2 Page/Line: 39/2 Statement to keep: validateTag: A string the Consumer MAY use to attempt to revalidate markup once the expires duration elapses. (section 6.1.5) Old text: The expires field of the cacheControl provides a time duration for when the markup SHOULD be considered valid. Once this time has elapsed, counting from the point in time when the MarkupContext structure was returned, the Consumer SHOULD use the validateTag field of the MarkupParams structure to inquire whether the markup is still valid, as this potentially avoids having the Portlet regenerate the same markup. New text: The expires field of the cacheControl provides a time duration during which it is valid to resupply the markup from a cache. Once this time has elapsed, counting from the point in time when the MarkupContext structure was returned, the validateTag field of the MarkupParams structure can be used by the Consumer to inquire whether the markup is still valid, as this potentially avoids having the Portlet regenerate the same markup. ID: C Section: 6.3.2 Page/Line: 40/1 Statement to keep: . In the case of performBlockingInteraction(), the Consumer MUST block all other invocations within the context of the initiating request from the client of the Consumer until either the receipt of a response or the invocation fails (e.g. times out). The Consumer then invokes getMarkup() on the Portlets being aggregated. (section 3.10) Old text: Since this is a blocking operation, the Consumer MUST wait for the response before invoking getMarkup() on the Portlets it is aggregating. New text: The Consumer has to wait for the response from performBlockingInteraction() before invoking getMarkup() on the Portlets it is aggregating. ID: D Section: 6.8 Page/Line: 44/42 Statement to keep: All Portlets MUST support the view mode. (section 6.8.1) Old text: A Portlet MUST support the view mode. New text: [delete] ID: E Section: 6.8.5 Page/Line: 45/30 Statement to keep: The Consumer MUST specify either one of the modes from the Portlet’s metadata or “view” (all Portlets are required to support this mode). (section 6.1.9) Old text: A Consumer MUST NOT set a mode the Portlet’s description has not specified as supported. New text: [delete] ID: F Section: 6.8.5 Page/Line: 45/35 Statement to keep: It is STRONGLY RECOMMENDED that custom modes, windowStates, and userAuthentication values be URI's or prefixed in a manner designed to reduce name clashes with any values that may be defined by future versions of this specification. (section 6.1.9 - separately CR#213) Old text: It is STRONGLY RECOMMENDED that custom mode values be URI's or prefixed in a manner designed to reduce name clashes with any values that may be defined by future versions of this specification. New text: Custom mode values are required to be URI's in order to reduce name clashes with any values that may be defined by other parties including future versions of this specification. ID: G Section: 6.9 Page/Line: 45/42 Statement to keep: All Portlets MUST support the normal window state. (section 6.9.1) Old text: A Portlet MUST support the normal window state. New text: [delete] ID: H Section: 6.9.5 Page/Line: 46/23 Statement to keep: The Consumer MUST specify either one of the windowStates from the Portlet’s metadata or “normal” (all Portlets are required to support this windowState). (section 6.1.9) Old text: A Consumer MUST NOT set a window state the Portlet’s description has not specified as supported. New text: [delete] ID: I Section: 6.9.5 Page/Line: 46/27 Statement to keep: It is STRONGLY RECOMMENDED that custom modes, windowStates, and userAuthentication values be URI's or prefixed in a manner designed to reduce name clashes with any values that may be defined by future versions of this specification. (section 6.1.9 - separately CR#213) Old text: It is STRONGLY RECOMMENDED that custom windowState values be URI's or prefixed in a manner designed to reduce name clashes with any values that may be defined by future versions of this specification. New text: Custom window state values are required to be URI's in order to reduce name clashes with any values that may be defined by other parties including future versions of this specification. ID: J Section: 7.2 Page/Line: 48/48 Statement to keep: All Producer registration processes MUST result in a unique, opaque token that may be used to refer to the registration. (section 7) Old text: Different registration contexts MUST be identified by different registrationHandles. New text: [delete] ID: K Section: 8.3 Page/Line: 52/17 Statement to keep: The Consumer MUST inform the Producer that a Consumer Configured Portlet will no longer be used by invoking destroyPortlets() and MUST NOT consider a Portlet to have been destroyed until destroyPortlets() has been successfully invoked for that Portlet. (section 8.4) Old text: The Consumer MUST attempt to release the new portletHandle by invoking destroyPortlets() when it is no longer needed. New text: The Consumer attempts to release the new portletHandle by invoking destroyPortlets() when it is no longer needed. ID: L Section: 10.1 Page/Line: 55/21 Statement to keep: When the SOAP binding is in use, the Producer MUST either use this character set or UTF-8 for the response message as the nature of XML requires the character set used for the markup to be the same as the response message. (section 6.1.9) Old text: When the SOAP binding is in use, the Producer MUST use the same character set for the XML response message as was used to generate the markup. New text: When the SOAP binding is in use, the nature of XML requires that the markup use the same character set as the XML response message. ID: M Section: 10.2 Page/Line: 56/29 Statement to keep: For Portlets setting this flag to “true”, Consumers MUST provide the URL writing templates. (section 5.1.11) Old text: If a Portlet’s metadata declares it is willing to process URL templates, then the Consumer MUST supply templates for the Portlet to use. New text: If a Portlet’s metadata declares it is willing to process URL templates, then the Consumer supplies templates for the Portlet to use. ID: N Section: 10.2 Page/Line: 56/31 Statement to keep: The Consumer MUST parse the markup for URL rewriting if this flag is set to “true”. (section 6.1.10) Old text: If the needsUrlRewriting flag in the MarkupResponse structure is “true”, then the Consumer MUST parse the returned markup and rewrite URLs conforming to the definitions in Section 9 of this specification. New text: If the needsUrlRewriting flag in the MarkupResponse structure is “true”, then the Consumer parses the returned markup and rewrite URLs conforming to the definitions in Section 9 of this specification. ID: O Section: 10.2.1.1.1 & 10.2.1.1.2 Page/Line: 57/36 & 58/8 Statement to keep: The value of this portlet URL parameter defines the navigational state the Consumer MUST send to the Producer when the URL is activated. If this parameter is missing, the Consumer MUST NOT supply the navigationalState field of the MarkupParams. (section 10.2.1.2) Statement to keep: The value of this portlet URL parameter defines the interaction state the Consumer MUST send to the Producer when the URL is activated. If this parameter is missing, the Consumer MUST NOT supply the interactionState field of the InteractionParams structure. (section 10.2.1.3) Old text: In addition the Consumer MUST check for the presence of the wsrp-navigationalState and wsrp-interactionState portlet URL parameters. If these parameters are present, their values MUST be supplied in the navigationalState and interactionState fields of the MarkupParams and InteractionParams structures, respectively. When these portlet URL parameters are not present, the Consumer MUST NOT supply the respective field. New text: [delete] ID: P Section: 10.2.4 Page/Line: 63/8 Statement to keep: If the Consumer uses this portlet, the Consumer MUST format its URLs in a manner that keeps user-agents from throwing away information (see section 10.2.4 for a description of the difficulties in using forms with method=get). (section 5.1.11) Old text: Consumers choosing to use such Portlets MUST format their portlet URLs such that portlet URL activations are processed correctly, regardless of whether Consumer or Producer URL writing is in use. New text: Consumers choosing to use such Portlets need to format their portlet URLs such that portlet URL activations are processed correctly, regardless of whether Consumer or Producer URL writing is in use. ID: Q Section: 10.2.2 Page/Line: 60/42 Statement to keep: For Portlets setting this flag to “true”, Consumers MUST provide the URL writing templates. (section 5.1.11) Old text: The Consumer MUST supply these templates for Portlets specifying doesUrlTemplatesProcessing as “true”. New text: The Consumer supplies these templates for Portlets specifying doesUrlTemplatesProcessing as “true”. ID: R Section: 10.2.2.1 Page/Line: 61/5 Statement to keep: see CR#229 Old text: The Consumer MUST process requests to change either mode or window state before invoking performInteraction(). New text: [delete] ID: S Section: 10.2.2.3 Page/Line: 61/13 Statement to keep: see CR#229 Old text: The Consumer MUST process requests to change either mode or window state before invoking performBlockingInteraction(). New text: [delete] ID: T Section: 11 Page/Line: 69/1 Statement to keep: For the fields this specification defines, the named profile items a Portlet uses MUST all come from the “Profile Name” column of the table found in section 11. (section 5.1.11) Old text: Portlets that need access to user information MUST declare in its metadata the specific user profile fields it needs using the names specified above. New text: Portlets that need access to user information MUST declare in its metadata the specific user profile fields it needs using the names specified above. ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]