OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

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


Subject: [wsrp-wsia] Change requests for TC Call, Tuesday, February 25th


There was a request that we try and walk through these requests in section 
order in order to reduce the context switching necessary. These have been 
so ordered with some commentary about the nature of the change request as 
well. 

I expect to walk through the change requests in this order:

Small editorial/grammar changes (I do not expect to walk through these 
unless there are objections):
167 – Correct mime types
      Section 5.1.10 / Page 19 / Line 36 
      Use actual mime types in example rather than common acronyms
171 – Make RegistrationState field use explicit.
      Sections 5.1.19 & 5.1.20 / Page 24 / Lines 2 & 21
      Title says it all
172 – explicitly useCachedMarkup
      Section 6.1.10 / Page 31 / Line 40-42
      By being explicit, the conformance statement can stand on its own

Substantive changes:
 142 – Remove performInteraction()? 
       Impacts many sections
       JSR168 has dropped the need for this operation. Do we still want to 
keep it? Basic trade-off is the additional functionality vs the additional 
complexity for understanding, implementing and testing.

 147 – Exposes Registration portType or requires registration?
       Section 3.5 / Page 11 / Line 34-35
       Proposal is to change a conformance statement from exposing the 
in-band technique for registering to the use of the requiresRegistration 
flag.

 170 – Producer providing UserCategory support for Portlets
       Section 5.1.1 / Page 20 / Line 4-5
       Proposal is to drop the conformance level language from the note 
that the Producer may actually provide this support on behalf of the 
Portlet.

 169 – Is resourceName usage a conformance statement?
       Section 5.1.5 / Page 17 / Line 19-20
       Question is the value of making the use of resourceName as an 
indirection in a ResouceList a conformance statement. Proposal is to keep 
the content, but not as a conformance statement.

 153 – Make resourceName optional?
       Section 5.1.5 / Page 17 / Line 23
       Proposal is to have semantics for not supplying a resourceName 
(namely that values for other locales are not supplied).

 151 – UserScope definition
       Section 5.1.11 / Page 19 / Line 19-20 + others
       Proposal change UserScope from a tri-value to an open-ended set 
with 2 predefined values. This drops the needs to use the extensions field 
just to carry the name of other semantics.

 155 – Resending UserContext semantics 
       Section 5.1.11 / Page 20 / Line 29
       Proposal is to clarify the semantics of new information being 
supplied for either UserContext or Templates.
 174 – Processing a new cacheControl
      Section 6.1.10 / Page 31 / Line 40-42
      Be explicit when useCachedMarkup is "true" and a new CacheControl is 
supplied, it replaces the previous one.

 156 – Reset + set properties semantics
       Section 5.1.14 / Page 21 / Line 37
       Proposal is for clear semantics when a property is included in both 
the reset and set arrays of a PropertyList.

 144 – Meaning of requiresRegistration field
       Section 5.1.18 / Page 23 / Line 17
       Proposal is for a new conformance statement for when 
requiresRegistration='true'.

 158 – ServiceDescription.locales definition
       Section 5.1.18 / Page 23 / Line 29
       Proposal seeks to clarify that not all LocalizedStrings will have 
values for all locales.

 168 – Nil desiredLocales => sendAllLocales?
       Sections 5.2 & 8.2 / Page/Line: 25/23 & 52/17
       Proposal is to drop sendAllLocales in favor of a nil value for 
desiredLocales

 141 – Add previous windowState and mode?
       Section 6.1.2 / Page 26 / Line 46
       This would place the burden of remembering the previous 
windowsState and mode on the Consumer and thereby permit the Portlet to 
know about interesting transitions that do not involve user interactions 
with the Portlet's markup.

 139 – Add optional UpdateResponse.isSecure?
       Section 6.1.13 / Page 34 / Line 32
       This would enable the return from performBlockingInteraction() to 
change whether or not the Portlet needs the client page to be secure.

 166 – Add UserProfile.profileItems?
       Section 6.1.18 / Page 64 / Line 18
       Proposal is for an explicit mechanism to carry string extensions to 
the UserProfile

 165 – Semantics of no userProfile vs no userProfile data
       Section 6.1.19 / Page 39 / Line 22
       Proposal is to inform Portlets when the UserContext is shared using 
a nil userProfile.

 173 – What does it mean to support registration?
       Section 8.3 / Page 52 / Line 20-22
       We have a conformance statement regarding Producers supporting 
registration. It currently points at the requireRegistration flag ... not 
an exact match.

 162 – Require Consumers to support UTF-8?
       Section 10.1 / Page 55 / Line 22
       Proposal notes that we imply the answer to this question is yes and 
suggests adding a conformance statement to that effect.

 143 – Properly encode '&' in examples and BNF
       Section 10.2.1 & 10.2.2 / Page 58 & 61 / Line 15 & 24
       Question raised is whether or not the fragment containing a URL 
destined for consumer rewriting needs to be strictly XML compliant. If so, 
our '&' should be changed to '&'.

 164 – Namespacing Portlet URL Parameters
       Section 10.3 / Page 64 / Line 18
       Alternate text suggested for clarity reasons.

 138 – How does info get to proxied resources (Insert a new section 10.4?) 

       Section 10.4 (insert a new section at this point in the spec)
       In addition to a new section to discuss proxied resources, this 
request raises the question of how does a resource get access to 
information. Current discussion has noted three existing techniques and 
proposed one new technique. The three existing are:
  1) Cookies that are properly defined/processed relative to cookie 
domains.
  2) URL-encoding of the information.
  3) URL-encoding of an indirection to the information.
The proposed new technique is to define HTTP headers that carry 
UserContext and UserProfile information. The portlet could use portlet URL 
parameters to control whether or not these two items are supplied to a 
resource.

Rich Thompson



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


Powered by eList eXpress LLC