[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interop] Multi-valued portlet properties
In the current schema, the any element is specified with namespace ##other, and therefore StringArray can't be directly used in a Property. I remember Rich also mentioning this in a call. Subbu Andre Kramer said the following on 11/10/2003 10:42 AM: > We have both a StringArray type and element defined in our schema, so > Richard is right in that we do not need a complex type. However, we > currently say nothing about which wsrp properties are mapped to > portlet preferences and the alignment note could address this (through > a jsr specific type or namespace). In the meantime, I would rather we > do not map string[] preferences at all than encourage (b - multiple > occurrences of a property name). > > regards, > Andre > > -----Original Message----- > From: Richard Jacob [mailto:richard.jacob@de.ibm.com] > Sent: 10 November 2003 16:54 > To: Rich Thompson > Cc: wsrp-interop@lists.oasis-open.org > Subject: Re: [wsrp-interop] Multi-valued portlet properties > > > > I would prefer a) > However why do we need a custom wrapper type here? > Couldn' the StringArray element defined in our xsd be the first > element in > the <any> array of Property? (or even not necessaryly be the first one) > This would mean that we don't need wsdl/schema introspection, right? > Therefor it would be straight forward to serialize/deserialize. > > I'm feeling uncomfortable with b) since it defines a semantics for a type > interpretation although we have a means to transport such an a type. > In addition it introduces an explicit semantics on how to handle the > properties, i.e. store one element with "name" but keep values in > array, be > carefull with the lang attribute, etc. > > We might want to think of a change of Property.stringValue to > stringValues > in a later version? > > However we have one additional topic with multivalues: form parameters. > InteractionParams holds an NamedString[] for formParams. Even if we > have a > multivalue param (name: value1, value2) we do a > (name,value1),(name,value2) > here. > Looking into html multivalue form submission, html uses the same scheme: > -----------------------------7d39412f05da > Content-Disposition: form-data; name="top5" > Michael Jackson > -----------------------------7d39412f05da > Content-Disposition: form-data; name="top5" > Nina Hagen > -----------------------------7d39412f05da > Content-Disposition: form-data; name="Submit" > Submit Query > -----------------------------7d39412f05da-- > > From the servlet request one can get an string[] holding the values for > "top5". > > 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 > > . > > > > > > > > > > > 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]