[wsrp-wsia] Re: WSRP wsdl and nav state in UpdateResponse

[Rich Thompson <richt2@us.ibm.com>]

Practically I do not see a distinction between a nil and an empty 
navigational state. My sense of the discussion before was to keep 
UpdateRespone.navigationalState as a required field in order to reinforce 
that whatever is returned is the new value (i.e. can't drop the return and 
expect the one supplied to performBlockingInteraction() to be maintained 
as the current navState).

I do agree with the semantics you specify, namely that the Consumer feeds 
back whatever navState it has, including the empty string. This 
combination means that markupParams.navigationalState will be nil only on 
the first getMarkup and any links that fail to specify the 
wsrp-navigationalState portlet URL parameter.

Rich Thompson




Richard Jacob@IBMDE
03/14/2003 07:06 AM

        To:     Andre Kramer <andre.kramer@eu.citrix.com>
        cc:     Andre Kramer <andre.kramer@eu.citrix.com>, Rich 
Thompson/Watson/IBM@IBMUS
        From:   Richard Jacob/Germany/IBM@IBMDE
        Subject:        Re: WSRP wsdl and nav state in UpdateResponse

yes, this would reflect the discussion.
As you say in practice we would anyway check for all three or to be more 
exact: for null or "" as currently there is no support to distinguish 
between nill or not passed (the stacks should check this).
What would be the semantics on MarkupParams then where navState is 
optional?
I would suggest:
If nill is passed to the consumer the consumer may ommit navState, if "" 
is passed the consumer has to pass back a navState with value ""?
This would be a clean semantics: whenever navState passed to the consumer 
is != nill then it has to pass the content back (even if it's "").


Mit freundlichen Gruessen / best regards,

        Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com




Andre Kramer <andre.kramer@eu.citrix.com>
03/13/2003 07:35 PM
 
        To:     Rich Thompson/Watson/IBM@IBMUS
        cc:     Andre Kramer <andre.kramer@eu.citrix.com>, Richard 
Jacob/Germany/IBM@IBMDE
        Subject:        WSRP wsdl and nav state in UpdateResponse


Looking again at the wsdl after the conf call, this is what we have in
UpdateResponse:
<element name="navigationalState" type="xsd:string" />

Do you also think we need to make navigationalState nillable? This would
force a producer to send a value or nill as spec discussion said: [R] but
may be null. In practice, I think a consumer would need to code for nill, 
""
and no navigationalState element being returned (given lack of schema
checking).

Document: wsdl
Section: complexType UpdateResponse
Requested by: Andre Kramer
Old text:
<complexType name="UpdateResponse">
                                 <sequence>
                                                 <element 
name="interactionResponse"
type="types:InteractionResponse" />
                                                 <element 
name="navigationalState" type="xsd:string"
/>
                                                 <element 
name="newWindowState" type="xsd:string"
minOccurs="0" />
                                                 <element name="newMode" 
type="xsd:string"
minOccurs="0" />
                                 </sequence>
                 </complexType>
New text:
<complexType name="UpdateResponse">
                                 <sequence>
                                                 <element 
name="interactionResponse"
type="types:InteractionResponse" />
                                                 <element 
name="navigationalState" type="xsd:string"
nillable="true" />
                                                 <element 
name="newWindowState" type="xsd:string"
minOccurs="0" />
                                                 <element name="newMode" 
type="xsd:string"
minOccurs="0" />
                                 </sequence>
                 </complexType>

regards,
Andre




----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>