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: RE: [wsrp-interop] getProperties: qname to names (String[]) mapping


The problem with #1 is the "{namespace}localName" is not an official
standard for representing QNames using a single string (even though we use
it ourselves internally) and requires custom parsing.  What happens when the
value is just "{xxxxyyyy" (missing "}") or the braces are missing
altogether, etc.? 

#2 or #3 will be most compatible if the standard is corrected in future
versions to be QNames instead of xsd:string.  

Note that the namespace for a QName is optional anyway, so with option #3,
it is entirely up to the producer whether it uses a namespace or not in the
QNames in describing and processing properties or whether to use extra logic
when processing getProperties.

Also with #2, if producers wanted additional uniqueness, they could
concatenate the namespace or some other text to the local name.

#2 is easiest for consumers and producers.  #3 requires changes to consumers
but gives producers the option of using QNames with the caveat that extra
processing will be required for getProperties.

Nader Oteifa

-----Original Message-----
From: Richard Jacob [mailto:richard.jacob@de.ibm.com] 
Sent: Wednesday, March 05, 2008 11:50 AM
To: wsrp-interop@lists.oasis-open.org
Subject: Re: [wsrp-interop] getProperties: qname to names (String[]) mapping

I've added this as finding 3 to out Wiki page
http://wiki.oasis-open.org/wsrp/WSRP_Interop_Discussions

here are some thought about pros/cons for the proposals:

1. seems the best was to go for me.
It provides the full information about the original qname in the value. It
is easy to construct a String from a qname on the consumer side as well as
creating a java/.net qname object from that string representation.

2. the information and assymetry strikes me a little bit. Portlets might
want to rely on the full qname, although it's a "private" property.
Portlet/Producer code needs to be adopted to receive the local part only
wheas the DB for example might have the full qname as a key.
It seems to make searches and coding logic more complex.

3. looks logical and promissing from the plain XML perspective.
Howver I would expect that most implementations use some WSDL to code
mappers which generates an object model from the WSDL/XSD.
In such auto-generated object models, the XML namespace information
typically gets lost.
The producer/portlet code would not have access to the XML elements from
the request message directly and might not be able to resolve the
namespace.

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


|------------>
| From:      |
|------------>
 
>---------------------------------------------------------------------------
-----------------------------------------------------------------------|
  |Richard Jacob/Germany/IBM@IBMDE
|
 
>---------------------------------------------------------------------------
-----------------------------------------------------------------------|
|------------>
| To:        |
|------------>
 
>---------------------------------------------------------------------------
-----------------------------------------------------------------------|
  |wsrp-interop@lists.oasis-open.org
|
 
>---------------------------------------------------------------------------
-----------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
 
>---------------------------------------------------------------------------
-----------------------------------------------------------------------|
  |03/05/2008 05:34 PM
|
 
>---------------------------------------------------------------------------
-----------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
 
>---------------------------------------------------------------------------
-----------------------------------------------------------------------|
  |[wsrp-interop] 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


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 




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