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

No that's not correct, there is no inheritance
of parental namespaces.

Also, there is no "empty"
namespace in XML.

An element is either in a namespace
or not.

for example:

<element1 xmlns:myNS="http:something">

  <myNS:subelement1>someValue</myNS:subelement1>

  <subelemt2>someValue</subelement2>

  <subelemt3 xmlns="">someValue</subelement2>

</element1>

subelement1 is in the "http:something"
namespace

subelement2 is not in any namespace,
it does not inherit from it's parent, however it could end up in the document's
default NS if it is defined

subelement3 is explicitly set to have
no namespace

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:

 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" <>

To:
Richard Jacob/Germany/IBM@IBMDE

Cc:
<>

Date:
10/30/2009 02:27 AM

Subject:
RE: [wsrp-interop] getPortletProperties
non QNamed property list resolution recommendation

One question first because
I want to make sure we’re all speaking the same language.  What namespace
does the property XML payload element wind up in when you specify an “empty”
namespace?  I just want to make sure we’re clear on terminology and
not mixing terminology of XML with that of JAVA and .NET.  I’m interpreting
that to say don’t specify a namespace, therefore the property payload
XML element will inherit the default namespace of the nearest parent scope
which would probably be WSRP. 

 

Is this correct?

 

Nader

 

From: Richard Jacob [mailto:]

Sent: Thursday, October 29, 2009 10:14 AM

To: Nader Oteifa

Cc: 

Subject: Re: [wsrp-interop] getPortletProperties non QNamed property
list resolution recommendation

 

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:



 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" <>

To:

<>

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