[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp-wsia] Issues for 1/14/2003 call
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC