Re: [wsrp-interop] getPortletProperties non QNamed property list resolutionrecommendation

[Richard Jacob <richard.jacob@de.ibm.com>]

No, why should it.
The payload is an array of anys and
each of them should have the property types' namespace.
Again, similar to event payloads I'd
say that the root element doesn't really matter here.

Mit freundlichen Gr��en / Kind regards
Richard Jacob
Team Lead Portal Standards & WCM development WSRP Standardization Lead
IBM Software Group, WPLC
WSS Websphere Portal Foundation Development 1
Phone:	+49-7031-16-3469	IBM Deutschland Research & Development
E-Mail:	richard.jacob@de.ibm.com	Schoenaicher Str. 220
		71032 Boeblingen
		Germany
IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsrats: Martin Jetter Gesch�ftsf�hrung: Erich Baier Sitz der Gesellschaft: B�blingen / Registergericht: Amtsgericht Stuttgart, HRB 243294

 

From:	"Nader Oteifa" <nader2@netunitysoftware.com>
To:	<wsrp-interop@lists.oasis-open.org>
Date:	10/20/2009 10:16 PM
Subject:	[wsrp-interop] getPortletProperties non QNamed property list resolution recommendation

---

A while back, I pointed out a problem in
the WSDL/spec where the call to getPortletProperties specified a list of
string-based property names and not a list of QNames.  In all areas
related to properties other than getPortletProperties, QNames are always
used.  We had a meeting or two and came up with a resolution.  I
had forgotten the exact resolution and so I went back to the OASIS web
site to research it.  Here is the text:
 
------------------------------------
3.getPortletProperties - mapping of qnames
to names string array 
--Original Comment: http://lists.oasis-open.org/archives/wsrp-interop/200803/msg00001.html

 
--Summary: the PropertyDescription type
declares property identifiers (names) being of type xsd:QName. However
the getPortletProperties() operation takes a names array as a first class
citizen parameter of type xsd:string maxOccurs="unbounded". A
mapping of the types is needed. 
 
-- Proposal: 4 options are discussed on
the ML: 
1.use java Qname as String notation as
used e.g. in JSR286 
2.use local part only 
3.use XML notation 
4.define well known extension 
 
-- Resolution: The most interoperable and
compatible with future versions is option 2. The solution is a follows:

 
Producers 
1.generate a PropertyDescription for portlet
properties (and this is only necessary for those) with an empty namespace
URI ("") and a local part 
 
2.Producers which expose portlets / backends
which indeed use Qnames for their portlet properties need to encode those
Qnames to fit into the local part of PropertDescription.qname only. Since
PortletProperties are private to the portlet/producer, the encoding of
an eventual Qname to a string is opaque to the Consumer and is a Producer
choice. 
 
3.Producers need to make sure that the
encoded results contain valid values for the local part of a Qname as defined
in the W3C Namespace 1.0 recommendation. 
 
4.upon receiving a getProperty(.., names)
operation, Producers which have choosen to encode the local part need to
decode the names' values with the algorithm chosen in 3.. 
 
Consumers 
1.Consumers pass only the local parts of
PropertDescription.Qname in the getProperty(.., names) operation as a String
value. 
2.Consumers should ignore the namespace
URI from PropertyDescription.QName 
3.the encoding of the local part is opaque
to the Consumer. Consumer must forward the value unchanged.
-----------------------------------------
 
Which can be found here: http://wiki.oasis-open.org/wsrp/WSRP_Interop_Discussions

 
I thought we recommended option 1 not option
2.  
 
With the current recommendation, what happens
when you use an empty namespace for the property name namespace and also
use a custom type for the property value?  Doesn’t that put custom
property value element  in the WSRP namespace on setPortletProperties?
 
 
Thanks.
 
Nader