[wsrp-wsia] Issues for this week's calls

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

Call on 1/7:
#169: Does refresh page (F5/Ctrl+R) re-invoke performBlockingInteraction?
  => I think this is up to the Consumer implementation. Many will do a 
redirect so that a refresh is just a getMarkup() (might be a good 
suggestion for the primer), but the Producer must be prepared for the 
End-User hitting the button a second time ...

#183:  markup charset different or the same as the XML response charset?
  => The spec does not currently mandate that these be the same. Some web 
stacks do not allow one to set the charset of the XML response ... Do we 
need to mandate they be the same? Clarify language about what happens if 
they are different? ...

#170: Scope of Producer-Consumer HTTP session
12/19 => Is this just a missing a missing word? MUST 'only' send for the 
same userContext? Revisit on 1/7/03 ... do we need to add verbiage about 
various lifecycle cases.

#154: Rename "entity" to "portlet" (reopened due to JSR168 change)
12/19 => change to ConfiguredPortlet, or PortletConfiguration or Portlet? 
Primer to try these ...
Gil circulated several versions ... time to choose. 

** Did not have a quorum on 1/2 ... tentative decisions were: **

#185: Remove concept of Roles from the spec
1/2 => Rename as (suggestions include activity, userType, userGroup) ... 
key is that this indicates a grouping of users for personalization 
purposes. "Role" name carries too many security concepts. Should this move 
into the userProfile from the userContext?

#174:  The Consumer SHOULD NOT assert a role for a role which the 
12/19 => Use "MUST NOT" alternative

#175:  Roles should be per-Entity and not per-Producer
1/2 => Shared definitions, entity specific support => current spec is good

#184: Can performInteraction return new navigationalState?
12/19 => Defer 1/2/03 => Dan Machek to report on whether JSR168 allows 
navState to change in render().
1/2 => No ... operation is just getMarkup() + interactionParams

#181: registration changes
          - proposal is: Drop the registration API so that registration is 

always out of band and do not pass any additional data. Whatever the 
Producer actually needs can be acquired/modified through its out-of-band 
system. 
1/2 => Leave in for v1 ... if other relationship establishing specs become 
available (grid), we may want to drop this for v2. Review how managing 
server address changes work and whether we tie business issues w/technical 
issues too strongly.

** End of tentative resolutions from 1/2 **

#179:  requestParameter semantics unclear
    (Does resolution impact tentative resolution of #165? => Consumer must 
strip the prefix it supplied for namespacing)
12/19 => Carsten to repost JSR168 portlet acting as a proxy case (does not 
has access to raw input stream). Revisit 1/2/03.

#165: The Consumer should not strip the namespace prefix from form 
parameters
12/12 => tentatively resolve as the Consumer is to strip the namespace 
prefix it supplied for making things like IDs unique.

#187: How does POST data reach the Producer?
12/19 => address with #179.


Call on 1/9:
#182:  Globalize the Address Type/User Information fields and Postal Code 
is missing.
  => This is delayed to here because I am trying to pull together a table 
comparing the internalization specs and what we now have

#195: user_info alignment with JSR168 and P3P
  => hopefully this is resolved by #182

#188: Rename urlType to wsrp-urlType
  => proposal is for consistency with other interaction parameter names, 
useful for Producer URL writing case.

#189: Add a {wsrp-fragment} interaction parameter
  => proposal is to supply a fragment identifier so that a Consumer 
written link can navigate to a particular place in the target document

#197: Define new interaction parameters ... wsrp-entityHandle and 
wsrp-userKey
  => allows templates to be generic rather than entity and user specific

#196: Consumer can not force consumer rewriting to be used for URLs
  => question raised was how the consumer can force Consumer URL rewriting 
to be used. Answer was a defaultTemplate that output the spec defined 
Consumer URL rewriting template. This led to a request to specify this 
default template somewhere (my preference is in the primer).

#190: Intent and scope of uniqueness of the entityInstanceID in the 
RuntimeContext
  => issue raises questions on the clarity of the description of 
entityInstanceID

#192: SessionContext and Cookies conflict
  => proposal is that sessionID and cookie support be declared as mutually 
exclusive

#193: Client enabling of cookie support
  => question is whether the spec should have a conformance statement 
about cookie support on Consumers

#194: Registration properties
  => proposal is for an appendix that defines names/types for some 
registration properties expected to be commonly used. Possibilities raised 
so far include:
    producerAgent, type=string, access=readOnly
    supportsDIME, type=boolean, access=readOnly
    supportsSOAPAttachments, type=boolean, access=readOnly
and a controversial one for "password"

#198: clone on write and EntityDescription.hasUserSpecificState == false
  => questions whether userSpecificState and personalization are 
orthogonal ... I think they should be.

#199: preferred title
  => Multiple questions raised:
  1) How optional is the Consumer's use of the entity's dynamic title? My 
take is this is completely optional from the spec, most portals are likely 
to respect it.
  2) Is the preferred title in the locale of the markup? Spec does not 
currently say this and probably should.
  3) Would it be useful for the preferredTitle to be a localized string 
(i.e. values for multiple locales can be returned)? I would think not as 
this is intended to be a dynamic title for the current markup.

#191: Returning binary data from getMarkup is not supported well
  => Description:
"A producer wishing to return binary MIME data can do so by specifying a 
binary markup type in  markupContext.markupType but must return the markup 
as ""string markup"" in MarkupContext. It is unclear how the data is 
encoded as a string (i.e. not specified by WSDL) and the Web stack is not 
leveraged. A related problem area is that of allowing the consumer to 
specify MarkupParams.markupCharacterSet versus the char encoding actually 
used by the Web method."
Proposed Resolution:
"Allow MarkupContext.markup to be base64 rather than always encoded to a 
string would address both issues and allows Web stacks to do the heavy 
lifting. Suggest replacing (in MarkupContext):
  <element name=""markup"" type=""xsd:string"" minOccurs=""0""/>
with:
  <element name=""markupString"" type=""xsd:string"" minOccurs=""0""/>
  <element name=""markupBytes"" type=""xsd:base64Binary"" 
minOccurs=""0""/>
This scheme de-seralizes bytes to/from byte[]. It can be readily mapped to 
an attachment (once WSDL support is more ubiquitous). Unfortunately, not 
all stacks support <choice/> so we can't use that more natural 
representation but the above does not waste any bandwidth as the elements 
are minOccurs=""0""."

#200: state fields encoded by developer as strings or by stack as base64
  => Description:
The state fields: registrationState, entityState, possibly navigationState 
and sessionID (but not windowState) would be better as type 
xsd:base64Binary. Removes questions of encoding details from spec and 
makes the Web stacks do all the XML encoding work. They can also become 
binary attachments or headers in future.
  => How does this interact with Consumers who try to push this 
information out to their client?

#201: performBlockingInteraction/performInteraction
  => proposal renames operations to performInteraction and 
performConcurrentInteraction

#202: The field schema in Modeldescription has no WSDL encoding
  => WSDL subgroup found current web service stack tools are not able to 
process ref=xsd:schema. A wsrp:schemaLocation attribute could be used to 
point XML Schema tools at an xsd document.