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