[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Groups - WSRP TC modified
WSRP TC has been modified by Richard Jacob (richard.jacob@de.ibm.com). Event description: USA Toll Free Number: 877-302-8255 USA Toll Number: +1 303-928-2609 PASSCODE: 8814427 Agenda: 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): 175 – Clarify available modes Section 5.1.10 / Page 19 / Line 39 Adds language for what modes are available and which should be described 176 – ID, Key and Handle not used in WSDL wsrp_v1_types.xsd Add comments about why the types Handle, ID and Key are not used in the WSDL 180 – Correct section reference Section 3.8 / Page 13 / Line 14 181 – Reword "block all" Section 3.10 / Page 13 / Line 33 Proposes rewording in the negative so that the word "block" is not used. 182 – Clearer definition of extensions field Section 5.1.6 + many others / Page 17 / Line 41 Proposal rewords this oft repeated statement. Substantive changes: 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. 178 – markupCharacterSet in MarkupContext Section 6.1.10 / Page 31 / Line 26 Proposal adds this field. Email discussion has suggested adding text referencing the RFC for mime types and providing an example for declaring the charset. 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 194 – P3P alignment Section 6.1.18 and 11 / Page/Line: 35/49 + pages 68-69 Notes that the change of the name field to personname was not carried throughout 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. 187 – Cacheability and perform*Interaction Section 6.3.x / Page 39 / Line 9 Two alternatives proposed for clarifying how the protocol has clues for interactions impacting caching. Discussion has centered around whether we want anything in the spec until we define full invalidation caching. 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 '&'. 177 – Templates MUST send placeholders Section 10.2.2.1 - 10.2.2.8 / Page 61 Change 'SHOULD' to 'MUST' for the placement of fundamental parameters in action, etc templates (not for the default templates). 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. 193 – Asserting multiple standard user categories Section B.2 / Page 77 / Line 25 Adds explicit statements that multiple std user categories can be asserted and that there are no correlations between them. 192 – Prevent localization of standard user category names Section 5.1.9 / Page 18 / Line 36 Notes that the description for std user categories are their names and they are not localized. 195 – Add registrationMethods Section 5.1.18 / Page 23 / Line 7 Proposal adds a field to enable a Producer to provide guidance for how to register. In-band technique is identified by the portType name as this eliminates dependencies on particular bindings while not inventing yet another name. Conformance statements: 179 – Drop duplicate extensions conformance statement Section 3.3 / Page 11 / Line 5-6 Proposal notes that this is a weaker version of a conformance statement from 5.1.1 183 – Drop extension field's conformance statement? Section 5.1.1 / Page 16 / Line 29 This changes the oft used statement about extensions to something more closely resembling defining the field. 184 – Handle truncation Section 5.1.2 / Page 16 / Line 41 Makes statement stand-alone 185 – ResetProperty name conformance statement Section 5.1.13 / Page 21 / Line 23 Makes statement stand-alone 186 – PropertyDescription name description Section 5.1.15 / Page 22 / Line 10 Makes statement stand-alone 188 – Conformance -> Semantics (#1) 26 proposed changes that drop conformance language that is viewed as untestable. 189 – Processing groupID duplicate Section 3.8 / Page 13 / Line 14-15 Proposal notes this is a duplicate and suggests a forward reference to the section instead. 190 – User Categories in PortletDescription Section 5.1.11 / Page 20 / Line 5-7 Proposal notes this is a duplicate conformance statement (ref: 5.1.9) using more convoluted English. 191 – Namespace prefixing Section 10.3 / Page 63 / Line 12 Changes SHOULD to MUST and notes that JavaScript names may not start with a numerical character. 196 – Making conformance statements stand-alone 20 requests to make various conformance statements sensible when they are extracted from the specification. 197 – Specifying WSDL file locations Section 14 / Page 72 / Line 2 Rewords this conformance statement to say the WSDL on OASIS is the normative copy of the WSDL. 198 – Require Consumers to supply CSS stylesheets? Section 10.5 / Page 65 / Line 20 Proposal adds a conformance statement requiring Consumer to support the std CSS classes the spec defines. 199 – Conformance -> Semantics (#2) 13 proposed changes that drop conformance language that is viewed as untestable. Date: Tuesday, 04 March 2003 Time: 12:00pm - 01:00pm Eastern Time View event details: http://www.oasis-open.org/apps/org/workgroup/wsrp/event.php?event_id=1107 PLEASE NOTE: If the above link does not work for you, your email application may be breaking the link into two pieces. You may be able to copy and paste the entire link address into the address field of your web browser. Referenced Items Date Name Type ---- ---- ---- 27 Mar 2003 wsrp-minutes-030304.htm Minutes
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]