Re: [wsrp] WSRP draft .9 comments

[Rich Thompson <richt2@us.ibm.com>]

Comments in-line

Rich

Michael Freedman <michael.freedman@oracle.com>

05/17/05 06:59 PM

To	wsrp <wsrp@lists.oasis-open.org>
cc
Subject	[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