Title: RE: [wsrp-interop] Multi-valued portlet properties
Producers (not consumers) must be prepared to accept multiple properties with the same name, yes, but free to map them down to one single value.
regards,
Andre
-----Original Message-----
From: Subbu Allamaraju [mailto:]
Sent: 11 November 2003 03:58
To:
Subject: Re: [wsrp-interop] Multi-valued portlet properties
Given that WSRP is platform-agnostic, I agree that this is a JSR issue.
This effectively means that portlet preferences can not be mapped
consistently to portlet properties in WSRP. However, as Richard
suggested, a more acceptable (and simpler, avoiding non-WSRP types and
introspection) solution is to allow multiple values in the WSRP schema
in a future version.
Nonetheless, given the current schema, the consumer must be prepared to
accept multiple properties with the same name.
Regards,
Subbu
Rich Thompson wrote:
>
> We are expecting this technical note to provide guidance on how to map
> various JSR168 issues into the WSRP protocol. Having preferences of
> type string[] mapped in a particular way is an example of such a
> mapping. In the absence of guidance, Producers should expect the only
> construct a Consumer will map into an array is a schema defined array
> construct. The purists would probably even argue that any other
> mapping would be an error.
>
> Rich
>
>
> *Subbu Allamaraju <>*
>
> 11/10/2003 09:05 AM
>
>
> To
> Rich Thompson/Watson/IBM@IBMUS
> cc
>
> Subject
> Re: [wsrp-interop] Multi-valued portlet properties
>
>
>
>
>
>
>
>
>
>
> Are we expecting the JSR168 note to provide guidance on interop issues?
> I hope not. To avoid future compatibility (1.0) and interop issues, it
> would help to resolve this ASAP.
>
> Regards,
>
> Subbu
>
> Rich Thompson said the following on 11/10/2003 05:58 AM:
>
> >
> > Since the only place we know of this being an issue is JSR168's use of
> > string[] for preference types, I think we should hold off this
> > discussion until the joint effort at producing a Technical Note
> > seeking to ensure interoperability across WSRP of two disparate JSR168
> > implementations gets going.
> >
> > Rich
> >
> >
> > *"Ross Fubini" <>*
> >
> > 11/10/2003 02:30 AM
> >
> >
> > To
> > "Subbu Allamaraju" <>,
> <>
> > cc
> >
> > Subject
> > RE: [wsrp-interop] Multi-valued portlet properties
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > I'd say we should use solution b), sending two values with the same
> > name, as a recommended practice for the 1.0 specification. We should
> > consider this change for 2.0 when we cast a close on preference storage.
> >
> > ross
> >
> > -----Original Message-----
> > From: Subbu Allamaraju [mailto:]
> > Sent: Sunday, November 09, 2003 8:55 AM
> > To:
> > Subject: [wsrp-interop] Multi-valued portlet properties
> >
> >
> >
> > To continue the discussion on the multi-valued portlet properties issue
> > that I brought up a couple of weeks ago, here is a summary of options:
> >
> > a. Use the predefined StringArray type. Producer introduces a custom
> > wrapper type to hold StringArray. Consumers introspect the response to
> > find the wrapper type.
> >
> > b. Add multiple Property elements for each value of a property. So, if a
> > property "p1" has two values "v1" and "v2", the consumer will receive
> > two Property elements one with value "v1" and the other with value "v2"
> > and both with the same name "p1".
> >
> > Arguments for (a) - clean, typed
> > Arguments against (a) - needs a schema extension, can't interoperate
> > without introspection
> >
> > Arguments for (a) - typed, does not require a schema extension
> > Arguments against (b) - multiple properties with the same name might
> > confuse consumers (although, with the current schema, it is perfectly
> > legal to send multiple properties with the same)
> >
> > Regards,
> >
> > Subbu
> >
> >
> > To unsubscribe from this mailing list (and be removed from the roster
> > of the OASIS TC), go to
> >
> http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php.
> >
> >
> > To unsubscribe from this mailing list (and be removed from the roster
> > of the OASIS TC), go to
> >
> http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php.
> >
> >
>
>
>
To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php.
