Re: [wsrp-interop] getProperties: qname to names (String[]) mapping

[Nathan E Lipke <nlipke@bea.com>]

Cons:
#1 Has a Java bias, not compatible if the schema changes
#2 Basically removes QName support in favor of simple strings (v1 style)
#3 Requires direct manipulation of elements and attributes, not generated code friendly
#4 Requires additional committee work and additional work to integrate into our stacks

Pros:
#1 Has complete namespace info in one field
#2 Will be XML compatible if the schema changes to be of type QName
#3 #2 pro plus namespace support
#4 Is completely XML compliant without adding our own parsing code

My opinion is #2 is probably the best solution as it is platform neutral and does not require direct element/attribute manipulation. Also, we can add QName support in a future release. To do this we should have a note stating:

Preference names should use the null ("") namespace. The value(s) in the names field of the of getPortletProperties will be interpreted as belonging to the null namespace regardless of the value of the current default  namespace (xmlns="...").

Nate

Nader Oteifa wrote:

C6C31BB9BBF0441A8A649D087669B322@n3o" type="cite">

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 



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

  

Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.