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

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

#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.


???: 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.


???: 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)?



Rich Thompson