[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
Even if this might argue in favour of b) I'd like again to point out that
we have a means defined in Property to handle this appropriatly.
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
|---------+---------------------------->
| | Rich |
| | Thompson/Watson/I|
| | BM@IBMUS |
| | |
| | 11/10/2003 03:14 |
| | PM |
|---------+---------------------------->
>--------------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: wsrp-interop@lists.oasis-open.org |
| cc: |
| Subject: Re: [wsrp-interop] Multi-valued portlet properties |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
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 <subbu@bea.com>
11/10/2003 09:05 AM To
Rich
Thompson/Watson/IBM@IBMU
S
cc
wsrp-interop@lists.oasis
-open.org
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" <rossf@plumtree.com>*
>
> 11/10/2003 02:30 AM
>
>
> To
> "Subbu Allamaraju" <subbu@bea.com>,
<wsrp-interop@lists.oasis-open.org>
> 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:subbu@bea.com]
> Sent: Sunday, November 09, 2003 8:55 AM
> To: wsrp-interop@lists.oasis-open.org
> 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
.
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]