Background

The WSRP TC voted to begin a public review on its approved Committee Draft 02 during a conference call on June 7, 2006 (minutes located at http://www.oasis-open.org/committees/download.php/18611/TC_Minutes_20060607.html). The public review was announced on June 14, 2006 (see http://lists.oasis-open.org/archives/members/200606/msg00006.html) and ran until August 13, 2006.

The WSRP TC voted to begin a second public review (15-day) on its approved Committee Draft 03 using electronic ballots (located at http://www.oasis-open.org/apps/org/workgroup/wsrp/ballot.php?id=1093 and http://www.oasis-open.org/apps/org/workgroup/wsrp/ballot.php?id=1094) The public review was announced on September 13, 2006 (see [http://lists.oasis-open.org/archives/members/200609/msg00009.html) and ran until September 28, 2006.

This file enumerates the comments received and their disposition.

Public Review 01 comments

Resolved comments

  1. Original comment: http://lists.oasis-open.org/archives/wsrp/200606/msg00027.html
    Summary: Clarity needed in how Consumers are to handle wsrp-navigationalState being specified on a resource URL. Status: Table this item until we can drive through the Ajax use case Mike has written up. Proposal: http://www.oasis-open.org/committees/download.php/20027/navState-gR.html Resolution: Proposal approved with clarifying edits. Impacts: Sections 6.3, 6.11.2, 10.2.3, 13 & schema

  2. Original comment: http://lists.oasis-open.org/archives/wsrp/200606/msg00028.html
    Summary: Clarify how NavigationalContext.publicValues work across various update scenarios.
    Resolution: Consensus is that the current semantics are correct -- absence of navParam indicates the portlet isn't changing the value. Presence of a navParam with no value indicates the portlet wants the value cleared. Though we agree this is what the spec says we think it can be stated clearer and propose that section 10.2.1.3 be updated with some wording to describe these specifics. Also, add a phrase in the last sentence of this section specifying this is an inclusive but not exclusive requirement.
    Impacts: Section 10.2.1.3

  3. Original comment: http://lists.oasis-open.org/archives/wsrp/200606/msg00030.html
    Summary: ExtensionPart needs a name field for the name of the XML element carrying the extension part.
    Resolution: Add a name field to ExtensionPart definition. Syntactically this defines the XML element name used to carry the ExtensionPart at runtime. Semantically this is a QName such that the extension can cleanly define semantics applying just to this part of the overall extension.
    Impacts: Sections 5.1.21 & 5.1.22 and the schema.

  4. Original comment: http://lists.oasis-open.org/archives/wsrp/200606/msg00031.html
    Summary: Schema is missing "minOccurs="0" maxOccurs="unbounded"" for ExtensionPart field within the ExtensionDescription definition.
    Resolution: Add "minOccurs="0" maxOccurs="unbounded"" to the schema definition of the extensionPart field of the ExtensionDescription structure.
    Impacts: Schema

  5. Original comment: http://lists.oasis-open.org/archives/wsrp/200606/msg00038.html
    Summary: Should the spec require full URL decoding such that escaping non-reserved characters works (e.g. &amp%3b decodes to the entity reference & which then resolves to '&')?
    Status: Consensus is building to require support for such decoding -- because we feel that Consumer's can implement an optimistic approach which only falls over to decoding when needed. However further thought/discussion is needed so folks can review possible implementations to ensure this can be achieved with reasonable/low cost. Ongoing discussions will continue in wiki thread.
    Rich & Subbu noted in further review that the spec is explicit about when URI encoding needs to be employed and that the relevant RFC states that percent encoding a reserved character will change how many applications interpret the URI.
    Resolution: After examining potential impacts on Consumer processing and the wording of both the WSRP specification and relevant RFC (#3986), it was resolved to not change the WSRP specification.

  6. Original comment: http://lists.oasis-open.org/archives/wsrp-comment/200606/msg00001.html
    Summary: Description of HandleEventsFailed.index is in the singular, but the field is an array.
    Resolution: Make the description use plural terms as this is meant to be an array.
    Impacts: Section 6.1.21

  7. Original comment: http://lists.oasis-open.org/archives/wsrp-comment/200606/msg00000.html
    Summary: Spam
    Resolution: Ignore as spam

  8. Original comment: http://lists.oasis-open.org/archives/wsrp/200607/msg00000.html
    Summary: The spec provides no guidance on how resources fetched with getResource can leverage standard web-based caching.
    Status: Seems there might be two questions here: do we detail requirements for what the Consumer does with regards to returning the resource to the client (i.e. does it write http cache headers) and does the consumer have sufficient information from our CacheControl structure to do so? Opinions on the first is that the spec shouldn't say anything about this. On the second we need to hear from Subbu to understand if/what concerns there are.
    Resolution: Work on as a v2 extension, preferably in the wsrp-extra namespace (no impact on v2 spec).

  9. Original comment: http://lists.oasis-open.org/archives/wsrp/200607/msg00001.html
    Summary: Mouse reference in CSS descriptions should be broadened to user's pointer.
    Resolution: Accepted however it was suggested that the first reference include a clarifying statement "such as a mouse".
    Impacts: Section 10.5.7

  10. Original comment: http://lists.oasis-open.org/archives/wsrp-comment/200607/msg00000.html
    Summary: Unclear implementation question (Rich requested additional clarification)
    Resolution: We determined this was not a question reading on the public review draft.

  11. Original comment: http://lists.oasis-open.org/archives/wsrp/200607/msg00002.html
    Summary: Spam likely with virus
    Resolution: Ignore as spam

  12. Original comment: http://lists.oasis-open.org/archives/wsrp/200607/msg00003.html
    Summary: Section 10.2.1.1.3 incorrectly says that wsrp-requiresRewrite applies to the case when wsrp-resourceID on a resource URL. Since this would invoke getResource, rewrite semantics are carried in the response rather than the URL.
    Resolution: Reword this conformance statement to require either wsrp-resourceID or the combination of wsrp-url and wsrp-requiresRewrite on a resource URL.
    Impacts: Section 10.2.1.1.3

  13. Original comment: http://lists.oasis-open.org/archives/wsrp/200607/msg00005.html
    Summary: It would reduce the complexity of language within the specification and developer confusion if getResource had its own structures for both incoming Params and the outgoing Response.
    Status: Use wiki Resource-specific_structures to define what these types would then look like. Note: approving these changes eliminates the value expected by the change back to v1 style proposed in comment #17.
    Resolution: Archive the current contents of the wiki page into the document archive and approve adding this proposal to the spec.
    Impacts: Sections 4.2, 6.1.13-6.1.19, 6.3, 10.2.1.1.3.4, 10.2.2.5, 10.2.2.7, 10.2.2.8, 10.2.3, Appendix E & schema

  14. Original comment: http://lists.oasis-open.org/archives/wsrp/200607/msg00006.html
    Summary: Section 8.1.5 incorrectly says "copyPortlet" rather than "copyPortlets". Also, the font does not correctly indicate this is an operation's name.
    Resolution: Fix this and the "CopyPortletResponse" in section 8.7 as well.
    Impacts: Sections 8.1.5 & 8.7

  15. Original comment: http://lists.oasis-open.org/archives/wsrp/200607/msg00007.html
    Summary: Figures in 10.5.6 and 10.5.7 have spell check indicators. Also, the colors make some things hard to read.
    Resolution: Ask the editor to update these figures to remove the spellcheck indicators and improve the color choice in the figure in 10.5.7.
    Impacts: Sections 10.5.6 & 10.5.7

  16. Original comment: http://lists.oasis-open.org/archives/wsrp/200607/msg00008.html
    Summary: This section states that portlets MUST NOT use tags like body, head, frameset etc. Proposal is to relax this to a SHOULD NOT with additional commentary that including these will reduce the number of Consumer implementations that can properly aggregate the Portlet's markup.
    Resolution: Leave language as is. Encourage the test kit to at least have Consumer, Producer and Portlet profiles.

  17. Original comment: http://lists.oasis-open.org/archives/wsrp/200607/msg00011.html
    Summary: Some v1 anonymous types became named types in v2. Why make this change?
    Status: Everyone encouraged look closer at how difficult it would be to support both v1 and v2 with the differences in what their tools generate from the wsdl.
    Resolution: Leave the schema as is

  18. Original comment: http://lists.oasis-open.org/archives/wsrp/200607/msg00010.html
    Summary: Two different element definitions for handleEventsResponse (lines 425 & 877 in the schema). While these use different casing (i.e. are not in conflict with each other), why have both definitions?
    Resolution: Move HandleEventsResponse type definition down with the rest of the message definitions and delete the first element definition referencing it.
    Impacts: Schema

  19. Original comment: http://lists.oasis-open.org/archives/wsrp/200607/msg00009.html
    Summary: Proposal for additional CSS classes and a mechanism for carrying what optional sets of classes a Consumer supports.
    Status: We should explore interactions of these classes with layout choices. We may want to explore a broader solution where portlets declare their CSS class sets and fall-back definitions to the Consumer.
    Proposal: http://www.oasis-open.org/committees/download.php/19783/CSS-proposal.html,

    Resolution: Define as a v2 extension

  20. Original comment: http://lists.oasis-open.org/archives/wsrp/200607/msg00015.html
    Summary: Yet more use cases needing render URLs with additional user-supplied, but portlet-defined query parameters (e.g. method=get issues). Richard has proposed adding a field (array of queryParameters) to MarkupParams.
    Status: How many of these use cases is already solved using public navigational parameters? Would it be interoperable across different Consumer encodings of public navigational parameters? Why does this issue keep coming up? Do we have time to consider all the ramifications in our v2 timeframe? One alternative would be for a group of interested parties to work on a v2 extension.
    Resolution: Solved in resolution to comment #28

  21. Original comment: http://lists.oasis-open.org/archives/wsrp/200607/msg00020.html
    Summary: WSRP protocol does not reflect the full set of http caching headers.
    Resolution: Work on as a v2 extension, preferably in the wsrp-extra namespace (no impact on v2 spec).

  22. Original comment: http://lists.oasis-open.org/archives/wsrp/200607/msg00029.html
    Summary: The WSRP spec uses the word "resource" in three distinct ways. This comment includes a proposal to eliminate one of those.
    Status: Everyone has been requested to review the list of proposed changes in detail. Rich particularly comment on the need to change Section 3.6, even if the other changes are not adopted.
    Resolution: Approved the proposed editorial changes.
    Impacts: Sections 1.3, 3.4, 3.6, 5.1.5, 5.1.25, 6.1.1, 6.1.4, 6.1.20, 6.6, 7.2, 7.4, 8.4, 8.8, 10.3, 14 and Appendix C

  23. Original comment: http://lists.oasis-open.org/archives/wsrp/200607/msg00030.html
    Summary: HandleEvents is the only user interaction oriented operation that can not be triggered directly from a URL. Proposal is to introduce a wsrp-urlType value to fix this.
    Status:
    Resolution: Deal with this using the URL extensibility resolution to comment #28.

  24. Original comment: http://lists.oasis-open.org/archives/wsrp/200607/msg00031.html
    Summary: Clarification of the usage for the mimeAttributes field is requested.
    Status:
    Resolution: Change descriptive text to "mimeAttributes: Attributes received from the client (e.g. http headers, other attributes relative to the upload file, etc.) that are not represented elsewhere within the protocol."
    Impacts: Section 6.1.29

  25. Original comment: http://lists.oasis-open.org/archives/wsrp/200607/msg00034.html
    Summary: How to carry changes to the set of events a Portlet can handle/produce?
    Status: If the proposed requestPing field is added to MarkupResponse, then defining events for both the Portlet and Producer metadata changing could address this need without having to wait for WS-Notification or WS-Eventing being widely adopted.

    • Note: Previous discussions had deferred consideration of this class of use cases until after the v2 timeframe.

    Resolution: Leave this as a deferred item.

  26. Original comment: http://lists.oasis-open.org/archives/wsrp/200607/msg00036.html
    Summary: The spec does not distinguish between markup restrictions related to gM() and gR().
    Resolution: Add a statement to section 6.3 noting that the restrictions from section 10.4 apply if the resource is markup that will be inserted directly into the aggregated page and not if the Portlet is using such markup in another manner.
    Impacts: Section 6.3

  27. Original comment: http://lists.oasis-open.org/archives/wsrp/200607/msg00037.html
    Summary: This comment notes that we have not addressed the question of how a portlet can impact the head section of a document (e.g. the contents of the HTML head element).
    Status: This use case has been raised before, but noone has spent the time/effort to make a proposal to address it. At this point, it could be addressed as a v2 extension.
    Resolution: Address as a v2 extension

  28. Original comment: http://lists.oasis-open.org/archives/wsrp/200607/msg00053.html
    Summary: While other areas of the WSRP protocol are extensible, URLs are not in either the urlType values or relative to additional url parameters.
    Status: Proposal posted, alternatives should also be developed ... (see http://www.oasis-open.org/committees/download.php/19811/ExtensionURLs.html)
    Resolution: Approve this proposal
    Impacts: Section 10.2.1.1.4, 10.2.1.9, 10.2.3, 12.2, Footnotes & "extra" schema

  29. Original comment: http://lists.oasis-open.org/archives/wsrp/200607/msg00067.html
    Summary: WSRP v2 only allows sharing one part of normal portlet transient state (i.e. navigational state), why isn't there a means to share session state as well.
    Status: Proposal developing on the wiki.
    Resolution: Do as an extension post v2 so time is available for implementation efforts to provide feedback about chatiness and Consumer complexity.

  30. Original comment: http://lists.oasis-open.org/archives/wsrp/200608/msg00033.html
    Summary: How should a nil description field of an ItemDescription be dealt with?
    Resolution: Update the schema to make the description field of an ItemDescription nillable.
    Impacts: Schema

  31. Original comment: http://lists.oasis-open.org/archives/wsrp/200607/msg00065.html
    Summary: Rich received a comment that since v2 is a superset of v1, the contributors from the title page of v1 should be on the title page of v2.
    Resolution: Leave the spec as it is

  32. Original comment: http://lists.oasis-open.org/archives/wsrp/200608/msg00006.html
    Summary: The portType/binding/filename names in Section 15 do not match the wsdl!
    Resolution: Update the names within the specification to match those in the wsdl.
    Impacts: Section 15

  33. Original comment: http://lists.oasis-open.org/archives/wsrp/200608/msg00007.html
    Summary: The spec contains several editor comments.
    Proposal:

    • RDT1 - WSN should be considered by the OASIS membership in September ...
      RDT2 - Just need to remove the comments as the document they related to (HTML/XHTML considerations) hasn't been written.
      RDT3 - Rich has requested stable URLs for the various WSRP v2 files on the docs.oasis-open.org server
      RDT4 - The Whitepaper does need updating to reflect the v2 work ...
      Security Tech Note - Do we want a "TechNotes" folder on the docs server so that stable URIs can be placed in documents for resources such as this which are likely to continue to evolve?

    Resolution: Delete RDT1 & RDT2, get stable URIs for items referenced by RDT3, RDT4 & Security_Tech_Note and then delete these comments and the section containing them
    Impacts: Sections 3.1.2, 10.4.1.1, 15, 16 & Comments

  34. Original comment: http://lists.oasis-open.org/archives/wsrp/200608/msg00015.html
    Summary: Notes mismatch on port/binding names and proposes including the v1 service wsdl rather than having two service elements.
    Status:
    Resolution: Leave the example service wsdl as is.

Public Review 02 comments

Resolved comments

  1. Original comment: http://lists.oasis-open.org/archives/wsrp/200609/msg00029.html
    Summary: Editorial comments impacting various sections of the specification.
    Proposed Resolution: [Rich] Approve these updates
    Impacts: Sections 6.3, 6.11.2, 10.2.1.3 and 10.2.4

  2. Original comment: http://lists.oasis-open.org/archives/wsrp/200609/msg00034.html
    Summary: Clarity needed in how publicValues relate back to a ParameterDescription.
    Proposed Resolution: [Rich] Editorial change to add the following sentence to the description of the publicValues field in 6.1.12: "Which of the Portlet's navigational parameters is being referenced is identified by using the value of the identifier field from the ParameterDescription, supplied with the Portlet's metadata, in the name field of the NamedString." Also an editorial change to make the last sentence describing the identifier field in 5.1.15 be: "The value in this field is used to reference the parameter on both URLs (see [Section 10.2.1.3]) and within the publicValues array of NavigationalContext."
    Impacts: Sections 6.1.12 and 5.1.15

  3. Original comment: http://lists.oasis-open.org/archives/wsrp/200609/msg00039.html
    Summary: Relax the language around the sending of extra URl parameters. Perhaps just to being explicit that they are sent on all requests to the target portlet during the Consumer's processing of the user interaction.
    Proposed Resolution: Add a phrase to the conformance statement clarifying that it only applies to WSRP defined urlTypes.
    Impacts: Section 12.2

  4. Original comment: http://lists.oasis-open.org/archives/wsrp/200609/msg00044.html
    Summary: Drop the event added in the resolution of comment #1 due to idempotency concerns.
    Proposed Resolution:
    Impacts: Section 6.11.2

Public Review 03 comments

Open comments

Resolved comments

  1. Original comment: http://lists.oasis-open.org/archives/wsrp-comment/200707/msg00000.html
    Summary: SPAM announcement of a Web API Workshop
    Status: Resolved
    Resolution: Ignore as spam
    Impacts: none

  2. Original comment: http://www.oasis-open.org/apps/org/workgroup/wsrp/email/archives/200707/msg00007.html
    Summary: Expand set of resource cacheability concepts
    Status: Resolved
    Proposal: http://lists.oasis-open.org/archives/wsrp/200710/msg00000.html
    Resolution: Adopt proposal
    Impacts: New section (11.3), 15, extra schema

  3. Original comment: http://www.oasis-open.org/apps/org/workgroup/wsrp/email/archives/200708/msg00000.html
    Summary: Supporting multi-valued property/event lists
    Status: Resolved
    Resolution: Add NamedMultiValue and QNamedMultiValue types to extra namespace
    Impacts: extra schema

  4. Original comment: http://www.oasis-open.org/apps/org/workgroup/wsrp/email/archives/200708/msg00001.html
    Summary: Array specification is missing for clientAttributes in xsd
    Status: Resolved
    Resolution: Fix xsd to match spec - editorial change
    Impacts: types scema

  5. Original comment: http://www.oasis-open.org/apps/org/workgroup/wsrp/email/archives/200708/msg00002.html
    Summary: Navigational values on action URLs
    Status: Resolved
    Resolution: WSPR v2 model for this area was well-discussed and is well represented in the specification - no change
    Impacts: none

  6. Original comment: http://lists.oasis-open.org/archives/wsrp-comment/200709/msg00000.html
    Summary: Various editorial comments
    Status: Resolved
    Resolution:
    4.1.11 - add phrase "Since the local name portion of an event's name"
    4.1.16 - leave as is
    4.1.27 - leave as is
    5.1.16 - change to "This field is only missing when the useCachedItem flag is "true" or the item is returned in the itemBinary field as this field is mutually exclusive with the itemBinary field."
    5.1.23 - add phrase "returned by performBlockingInteraction or handleEvents"
    5.4.3 - correct to "MUST"
    13 - change to namespace to the appropriate v2 one
    Impacts: 4.1.11, 5.1.16, 5.1.23, 5.4.3 and 13

  7. Original comment: http://lists.oasis-open.org/archives/wsrp-comment/200709/msg00001.html
    Summary: Identifies several structures which now use LocalizedString, but do not contain a ResourceList
    Status: Resolved
    Resolution: Add missing ResourceLists to top level structures
    Impacts: 5.1.26, 6.1.1, 7.1.1, 7.1.11

  8. Original comment: http://lists.oasis-open.org/archives/wsrp-comment/200709/msg00002.html
    Summary: Wrong type referenced for getResourceResponse in the interfaces wsdl
    Status: Resolved
    Resolution: Editorial error - correct as per comment
    Impacts: interfaces wsdl

  9. Original comment: http://lists.oasis-open.org/archives/wsrp-comment/200709/msg00003.html
    Summary: Spam
    Status: Resolved
    Resolution: ignore as spam
    Impacts: none

  10. Original comment: http://lists.oasis-open.org/archives/wsrp-comment/200709/msg00004.html
    Summary: Clarity sought on "perUser" CookieProtocol
    Status: Resolved
    Resolution: leave as is
    Impacts: none

  11. Original comment: http://lists.oasis-open.org/archives/wsrp-comment/200709/msg00005.html
    Summary: Mismatch between spec and wsdl for EventPayload
    Status: Resolved
    Resolution: Add comments similar to those describing the same situation for the Property structure
    Impacts: 5.1.21

  12. Original comment: http://lists.oasis-open.org/archives/wsrp-comment/200709/msg00006.html
    Summary: Clarify how portletStateChange impacts processing multiple events against a single portlet?
    Status: Resolved
    Resolution: Add a pair of SHOULD level statements discussing special considerations relative to "cloneBeforeWrite"
    Impacts:5.4.2.2

  13. Original comment: http://lists.oasis-open.org/archives/wsrp-comment/200709/msg00007.html
    Summary: Mismatch between the naming convention in section 10 and P3P/others
    Status: Resolved
    Resolution: Leave as is was in v1
    Impacts: none

  14. Original comment: http://lists.oasis-open.org/archives/wsrp-comment/200709/msg00008.html
    Summary: Retrieving current registration properties is not currently supported, but use cases have been identified
    Status: Resolved
    Resolution: Do as an extension - consider inserting into specification if it is ready in time
    Impacts: new 11.4?

  15. Original comment: http://lists.oasis-open.org/archives/wsrp-comment/200709/msg00009.html
    Summary: Mapping to the multi-phase render of JSR-286
    Status: Resolved
    Resolution: Do as an extension - consider inserting into specification if it is ready in time
    Impacts: new 11.5?

WSRP_v2_Public_Review_comments (last edited 2009-08-12 18:06:28 by localhost)