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] WSRP draft .9 comments

Comments in-line


Michael Freedman <michael.freedman@oracle.com>

05/17/05 06:59 PM

wsrp <wsrp@lists.oasis-open.org>
[wsrp] WSRP draft .9 comments

I have made it through section 6.4.  Here are my comments so far:

1.        supportedFeatures in serviceDescription:  should we prefix these with wsrp: thereby allowing non-standard features to referenced [aka extensions].
<rt> Agreed ... do people think these should also have a 1-2 sentence explanation?</rt>

2.        Lifetime in both RegistrationState and RegistrationContext.  This sticks out like a sore thumb.  It seems to be there so ModifyRegistration can continue to return a RegistrationState.  I suggest instead it return a ModifyRegistrationResult that contains both a RegistrationState and a Lifetime.  If we do this should each be optional and signify that that omission means no changes?  Or does the producer have to explicitly return items because omission means null?
<rt> The wsdl now recognizes the relationship between these two structures by having RegistrationContext extend RegistrationState to add the registrationHandle field. Should we just add a comment explicitly stating this in the spec?</rt>

3.        ClientData Type section.  First sentence is:  "The MarkupParams structure carries information concerning the user agent using this type."  This seems out of date.  Suggest a better introduction to what the clientdata structure is about.
<rt> How about "The ClientData structure carries information regarding the characteristics of the user agent and device used to render the markup for the End-User."</rt>

4.        HandleEventsFailed is inconsistent with our CopyPortlets/Import/ExportsFailed structures.  Should we reconsider and have the structure return the QNames of the events that failed [and multiple for any given reason].  Do we really care to handle the odd situation that the array contains the same events twice?  We could always tell the Consumer that if it is bothered by this to send them in different requests.  Another possibility is that the Event type get a new field to carry a consumer supplied ID that can be used to reference in the subsequent failed array.
<rt> The consistent format is reference to failed item, faultCode and localized reason. I certainly am willing to reopen the discussion of how to reference which events failed (thanks for catching that this should be an array), but would note that adding an ID to the event was rejected as too expensive for the rare case of the Consumer caring about failures to process notifications. Anyone have a strong preference between the index (current) and the eventName?</rt>

5.        Section 6.1.23 EventParams Type -- description of portletStateChange:  reference that this impacts processing of an event needs to be updated to reflect that handleEvents is now a bulk operation.  Second sentence seems to have a misplaced semicolon.
<rt> Semicolon deleted from both 6.1.22 and 6.1.23. Changed "an event" to "events" due to bulk nature of handleEvents.</rt>

6.        Can someone clarify the use case for resource form submission/file upload?  Is this merely because we didn't prohibit it in 1.0?  Should we be more restrictive in our API?  Part of my objection is this gives the portlet a loophole to change state during render but without access to navigational state updates.
<rt> I think there were several; 1) Certain technologies (including ASP, I think) carry their state using hidden form fields and therefore form submission is the expected means for receiving this back with activated URLs, 2) Consider a search result that says it has 342 pages (i.e. a large number) and allows the user to enter a page number to jump to ... rather than refreshing the entire page, such a portlet could consider the search results as a resource and fetch a different one for placement within the page. Again, browser technology makes this easier if the entry field is encapsulated within a form, 3) any other use cases people would want to raise?

        I would agree that there is the risk of a portlet changing state without being able to change navState, but would note two related items; 1) this is no different from the portlet writing to its session in getMarkup and 2) since resources are at a finer granularity than the portlet, it hasn't navigated to a new page (after all, there can be multiple resources within any single view), though it would be nice if a page refresh for the search results use case didn't reset to the last page generated via a pbia (likely requires the portlet store the currently displayed page in a session)</rt>

7.        Section 6.3 Getresource:  sentence [line 2253] "This operation is used whenever the URL activated has ..."  would be better as "This operation is used whenever the activated URL has ..."
<rt> Agreed ...</rt>

--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]