WSRP TC has been modified by Richard Jacob ().
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
