Re: [wsrp-wsia] Spec v0.92

[Michael Freedman <Michael.Freedman@oracle.com>]

Title:

My take on the open change requests:

138 – How does info get to proxied resources
> I think there are two questions we should answer before getting
> into the details of how to accomplish this.  First, does JSR 168 function
> strongly suggest we should define something here?  And if not, should we
> care anyway?  My contention is that the answer to the first question is yes
> -- as there will be JSR 168 implementations that use the UserId/Categories
> as a means for communicating access/content capabilities from the portal
> to the portlet.  It would be highly inappropriate for our protocol to require
> such a portlet to encode this information so it must be visibily passed all
> the way through to the client to get it transferred back to the resource.
>   
> Once/If we decide to address this problem it seems we have two alternatives
> to choose from:  
> a) extend the existing proxy resource design to support this OR
> b) augment/remove our existing proxt resource design with one where resources
> are executed by calling the portlet using the WSRP protocol.
>   
> Personally, I think either of this can be made to work and would be willing
> to work to solve the issue identified herein in either model.  Andre has
> provided a basic description for (b).   Here is a quick outline for (a):
> 1) define a new URL token in the proxy resource URL called sendUserContext.
>  Its value would be either "true" or "false".  If a value other then a case
> insensitve "true" is set the value is treaetd as "false".  If the token isn't
> included the value is treated as "false".  sendUserContext="true" means the
> portal is to send the UserContext information to the requested proxy resource.
>  For this release I suggest we only define the capability to send UserId
> and Categories -- we can deal with Profile later.  UserID would be sent in
> the http header  "x-wsrp-usercontext-key".  The value of this header would
> be a single string containing the usercontextKey.  The UserCategories would
> be sent in the http header "x-wsrp-usercontext-categories.  The value of
> this header would be a comma delimited list of user categories that apply
> to the request/userContextKey.
>   
141 – Previous WindowState/Mode
> I don't think we will be able to resolve this tomorrow.  Rather
> we should use a set amount of time to introduce folks to the problem, talk
> about the requirements I sent out earlier in the day and make some determination
> on how/whether to proceed with the discussion via e-mail
>   
207 – PortletDescription dependent on UserContext?
> I don't think we should add the suggested clarification nor drop
> passing the UserContext. The word "restrict" defines the right semantics
> -- you may get less information. By using this word I think there is no confusion
> that someone would mistakenly provide different values for the same fields
> to different users.  I don't think we should drop UserContext as it does
> provide value to the consumer particularly in indicating whether this user
> can utilze this portlet [or what it can utilize].  Some consumer's will choose
> to reflect this information  to the user when they are interacting with the
> portlet toolbox -- e.g. portlet's you can't access won't be displayed in
> the toolbox on a per user basis.
>   
213 – Require modes, windowstates & userAuthentication are URIs
> I don't think we should adopt this change.  It is not conveniently
> enforceable as we don't have a well defined means mechanism for a consumer
> to signal errors to the producer.  What does a consumer do if the requirement
> isn't met?  Refuse the declaration -- that's okay as a consumer isn't required
> to map any of the extensions anyway.  The bothersome thing is that the portlet
> developer will have a hard time debugging why the consumer isn't even offering
> the opportunity to map these custom modes, etc -- they won't be able to detect
> whether the consumer provides this capability or there was an error in the
> format.
>   
> If we want to avoid nameclashes I suggest we keep this as a SHOULD and redefine
> all our values to be URI based and explicitly reserve "wsrp" in this URI
> namespace.
>   
215 – Delete statement about “private conversational state”
> I agree this paragraph is not needed and removing it improves
> clarity.
>   
230 – Setting navState
> I agree the rewording is an improvement however I get a little
> lost in the parenthetical.  How about "To exist, navigational state must
> be set explicitly on each interaction or render request or by setting its
> value upon return from performBlockingInteraction()"?
234 – Delete section B.1
> As the issue states the one predefined property isn't really
> a property, thus should be removed.  Once removed there is no poin in having
> this section until sometime in the future when we add such properties.
      -Mike-





>



Rich Thompson wrote:
> I have reflected the change request resolutions to-date into the spec to 
> produce this version. I think the following are all the open items still 
> needing resolution:
>
> Left open at the Jan F2F:
>  - Sasha to propose language for 1.2.4 about what the protocol enables 
> End-Users to do.
>  - WSDL subgroup to explore a more "natural" way to carry xml markup. 
> (current best is in the markupBinary field)
>  - Desire to rename the MarkupType Type. Suggestions have included 
> MarkupSupport and MarkupFormat. Any others?
>
> Open Change Requests:
>  - 138 – How does info get to proxied resources
>  - 141 – Add previous windowState and mode?
>  - 207 – PortletDescription dependent on UserContext?
>  - 213 – Require modes, windowstates & userAuthentication are URIs (This 
> was in the set that was blanket adopted and is reflected in v0.92, but is 
> enough different from the discussion of the blanket adopted set that I am 
> calling it out here.)
>  - 215 – Delete statement about “private conversational state”
>  - 230 – Setting navState 
>  - 234 – Delete section B.1
>
>
> The "marked" version has had all of the formatting changes accepted so 
> that it is easier to see the insertions and deletions. The second copy has 
> had all changes accepted for those who find the change marks distracting.
>
>
>
> An item that has been discussed in the WSDL subgroup that also merits 
> calling out is that we define two types in our WSDL (StringArray and 
> NamedStringArray) that we do not use. They have been left in the 
> definition for possible use by extensions.
>
> Rich Thompson