Re: [wsrp-wsia] Issues for 1/14/2003 call

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

My notes distilling the discussion of the issues is intertwined with "1/14 
=>" indicating the discussion points. Since there was not a quorum, the 
actual resolutions will have to be taken up on Thursday.





Rich Thompson/Watson/IBM@IBMUS
01/13/2003 04:07 PM
 
        To:     wsrp-wsia@lists.oasis-open.org
        cc: 
        Subject:        [wsrp-wsia] Issues for 1/14/2003 call

#197: 1/14 => Add wsrp-sessionID (and others from 1/9) as interaction 
parameter for Producer templates only


#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:
    (directly coorelated to consumerAgent) producerAgent, type=string, 
access=readOnly
    (no, discover through wsdl) supportsDIME, type=boolean, 
access=readOnly
    (no, how is it normally discovered?) supportsSOAPAttachments, 
type=boolean, access=readOnly
and a controversial one for "password"
1/14 => Push end-point security use definitions to security TCs.
        Add such a non-normative appendix only if time permits ... it 
should also include the technique people should use to expand the list


#198: clone on write and EntityDescription.hasUserSpecificState == false
  => questions whether userSpecificState and personalization are 
orthogonal ... I think they should be.
1/14 => hasUserSpecificState is intended as a flag encouraging the 
Consumer to pre-clone (e.g. a mailbox portlet) while clone-on-write 
semantics also include user personalizing setting (e.g. setting the 
zipcode for a US weather portlet).


#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.
1/14 => 1) preferredTitle use is optional
        2) preferredTitle locale, markupType, etc MUST match the markup
        3) just a string, especially if #2 provides the locale of that 
string


#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""."
1/14 => This change would enhance support for DIME in v1. It would require 
defining additional semantics, including that these fields are mutually 
exclusive (preferred form would have been a <choice/>, but current tools 
don't properly support such definitions).
 - Continue to consider impacts for deciding 1/16.


#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?
1/14 => Binary encoding makes sense for registrationState and 
portletState.


#201: performBlockingInteraction/performInteraction
  => proposal renames operations to performInteraction and 
performConcurrentInteraction
1/14 => no strong reason to change. New name suggestions don't improve 
carrying the semantics of the difference in the operations.


#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.
1/14 => schema inline is sufficient for many simple cases and provides for 
using the schema include or import to pull in external definitions. 
Defining a schema element of type "any" for v1 doesn't seem too bad.


???: Move section 1.4 to 3.14
 => Why?
  1. It really is a General Design Issue, not Introductory material.
  2. This places right "Load Balancing" after the more general section 
about cookies ("Transport Issues").
  3. It moves all of the conformance statements out of the introduction.
1/14 => no objection


???: ResourceValue and LocalizedString are very similar, but carry their 
values differently.
 => Would people prefer carrying these strings as attributes 
(LocalizedString style) or as a child element (ResourceValue style)?
1/14 => Some preference for element.

???: inconsistent ResourceList handling
1/14 => 2 proposals:
 1) Every structure that contains a field of type LocalizedString also 
contains a ResourceList for the localized values. Downside is a lot of 
redundant structure for types that are included in arrays (e.g. 
UserCategoryDescription).
 2) When processing a field of type LocalizedString, the localized values 
are found by looking up the runtime containing structure until a 
ResourceList is found and this is where all localized values MUST be 
placed. Downside is the added complexity of producing/processing the 
correct indirections.

???: array representation

Rich Thompson

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>