I think the only argument I often heard was, because it's XML and we want
to enable the complete power of XML.
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Team Lead & Technical Lead
WSRP Standardization
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
Subbu Allamaraju
<subbu@bea.com>
To
03/22/06 05:19 PM Richard Jacob/Germany/IBM@IBMDE
cc
Michael Freedman
<michael.freedman@oracle.com>, wsrp
<wsrp@lists.oasis-open.org>
Subject
Re: [wsrp] Navigational parameter
restrictions
Could someone remind why we considered complex types, and even
considered an encoding strategy to encode complex types into URLs?
Subbu
Richard Jacob wrote:
Yes, I totally agree and did from the beginning :-)
I think the most use cases can and will be easily covered using just
scalar
types. It also enables an easier mapping of such parameters and eases
mapping UIs.
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Team Lead & Technical Lead
WSRP Standardization
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
Michael Freedman
<michael.freedman
@oracle.com>
To
wsrp <wsrp@lists.oasis-open.org>
03/21/06 10:40 PM
cc
Subject
[wsrp] Navigational parameter
restrictions
Should we restrict the returned navgiationalParameters in UpdateResponse
to only be values representing xml scalar types [int, string, etc.]?
The issue here is similar to the one that caused us to restrict what the
producer can encode in the URLs it writes into markup, namely many
consumers will prefer to manage these values in the same way they manage
navigational state. As this is commonly handled by writing the state
into every URL in the page, shouldn't we make it easy for a consumer to
do so? If so, should we back track all together and only support scalar
types? Or do we preserve the full open model for those properties that
aren't set by producers and might presumably either be computed by the
consumer vs. being encoded?
-Mike-
---------------------------------------------------------------------
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