[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]