OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interop message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: getProperties: qname to names (String[]) mapping



the last time we discussed how to map the qnames defined for portlet
properties to the getPortletProperties() operation which takes a names
string array as parameter identifiers.
In the xsd, the operation is defined as follows:
  <complexType name="getPortletProperties">
    <sequence>
      <element name="registrationContext"
type="types:RegistrationContext" nillable="true"/>
      <element name="portletContext"        type="types:PortletContext"/>
      <element name="userContext"           type="types:UserContext"
nillable="true"/>
      <element name="names"                 type="xsd:string"
nillable="true" maxOccurs="unbounded"/>
    </sequence>
  </complexType>
  <element name="getPortletProperties"
type="types:getPortletProperties"/>

We came up with 4 proposals:

1. use java qname notation as used for example in the JSR286 deployment
descriptor
This maps a Qname(NSURI, localpart) to the String "{NSURI}localpart"
A request would look as follows:

<getPortletProperties>
  <registrationContext>...</registrationContext>
  <portletContext>...</registrationContext>
  <userContext>...></userContext>
  <names>{http://example.org}propertyName1</names>
  <names>{http://example2.org}propertyName2</names>
</getPortletProperties>

The qname representation is derived from the name attribute in the
PropertyDescription complexType.

2. use the local part
The argument here was, that PortletProperties are local to a portlet
anyways and therefor a "virtual" default NS could be applied.
A PropertyDescription with qname=(http://example.org, propertyName1) would
become to "propertyName1", example:

<getPortletProperties>
  <registrationContext>...</registrationContext>
  <portletContext>...</registrationContext>
  <userContext>...></userContext>
  <names>propertyName1</names>
  <names>propertyName2</names>
</getPortletProperties>

3. use XML notation
the proposal would rely on XML support of adding NS declarations to
elements and refer to those declaration in the element value, example:
<getPortletProperties>
  <registrationContext>...</registrationContext>
  <portletContext>...</registrationContext>
  <userContext>...></userContext>
  <names xmlns:x='http://example.org'>x:propertyName1</names>
  <names xmlns:y='http://example2.org'>y:propertyName2</names>
</getPortletProperties>

4. use an extension to provide the full qname to the operation
I think this solution would be ruled out, since the getPortletProperties
complex type is not extensible at that level.
Only its subtypes are extensible, wheras the names[] is a first class
citizen of getPortletProperties.


Mit freundlichen Gruessen / best regards,

        Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept. 2289, WebSphere Portal Server Development 1
WSRP Team Lead
WSRP Architecture & Standardization
Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888

IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]