[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp-interop] getProperties: qname to names (String[]) mapping
I agree with Nader that 2 + 3 might be the best ones regarding future
compatibility. But I would presume that a 2+ version is quite in the far
future and would require a new schema namespace anyway.
but yes the commmon layer/abstraction layer would then behave similar with
less code changes towards the backend.
What worries me is that the producer might pick up the qnames for
properties from a component and might need to forward the (full) qname
again towords the portlet on the getPP() call.
So this would result in the need for the producer to generate a qname to
string mapping on its own anyway and parse it back to a qname once it
processes the resquest.
I'm not sure we should mandate that portlets (what ever application that
might be to which the producer bridges) should use an empty namespace for
their properties in order to work with WSRP.
So with 2&3 the schema would be:
1. producer picks up qname Q1 from component
2. producer generates a new qname Q2 with "" namspace and packs the Q1 data
into the local part of Q2
3. consumer picks up Q2 from portlet description
4. consumer just forwards the local part to producer (which contains an
producer chosen encoding of Q2
5. producer generates Q1 from Q2 received from getPP()
I can go with this scheme either, it puts the burden on the producer to
completely to encode itself correctly.
The only negotiation we would need then is, that consumers just forward the
local part in getPP()
Solution 1. has similar implications but would need an agreement of
encoding which maybe worse then 2.
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: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Nathan E Lipke <nlipke@bea.com> |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Nader Oteifa <nader2@netunitysoftware.com> |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Cc: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|wsrp-interop@lists.oasis-open.org |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|03/05/2008 08:50 PM |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Re: [wsrp-interop] getProperties: qname to names (String[]) mapping |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
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:
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.orgSubject: 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_Discussionshere 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]