OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interop message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [wsrp-interop] Re: [wsrp-conformance] RE: [wsrp-interop] foll ow-up: templates

Good analysis.
I agree to a, b, c - at the bottom line it comes to "replace them", since
b) is opaque one could consider no substitution as being indeed a
substitution, i.e. the consumer would pass {wsrp...} back to the producer,
the producer needs to handle it in that case.
{wsrp-secureUrl} should be categorized as c) not as e).
Since we defined a default value (false) one could even argue that a
no-change falls back to default.
However I would prefer to replace here anyways.

On d):
Leaving {wsrp-...} seems the most appropriate here unless we have a special
wsrp-value for that (e.g. "wsrp:null").
It seems more natural to indicate a no-change to me.
This would make {wsrp-...} reserved tokens in the spec. (perhaps we should
do that for any wsrp defined string anyway in 1.1).
I think the argument that a mode or window state might carry {wsrp-..} on
purpose is not strong enough. In the spec we encourage (although not
enforce) people to namespace their self-defined values so my expectation on
clashes is very low here.

On e):
what is {wsrp-token} for again? Didn't we miss to remove it once we dropped
the namespace URL thing?
This leaves it at {wsrp-fragmentID} being the only one left in e).
Here I would handle it as d), no substitution means "not set".

What strikes me a little bit is the fact that we introduce a more
complicated semantic in this processing, people might get confused.
It would be easier to understand if we said:
Required tokens on an URL must be replaced with values as well as all
portlet URL params (
All optional tokens don't need to be substituted (or better: have our
"wsrp:null" for that) and fall back to default.

One additional point: If we introduce d) don't we contradict our
conformance statements in and where we say that
modes/window states MUST be either the wsrp-defined ones or custom ones
supported by the producer? So a "MUST replace" here perhaps would fit
better? (btw. what makes it complicated for the producer to replace the
{wsrp-mode} with the current mode value the portlet is in? This would mean
for templates: staying in the same mode is a transition from mode x to mode
With that argument it would put a) b) c) d) into one equal group: "MUST
Then we would only have e) with "leave-as-is" which is little bit
underspecified (as Andre said).
This seems even an easier semantics to me.

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>      |
|         |                            |
|         |           11/10/2003 10:40 |
|         |           AM               |
  |                                                                                                                                                  |
  |       To:       wsrp-interop@lists.oasis-open.org                                                                                                |
  |       cc:                                                                                                                                        |
  |       Subject:  RE: [wsrp-interop] Re: [wsrp-conformance] RE: [wsrp-interop] foll       ow-up: templates                                         |

Agree, there are multiple cases here:

a) tokens spec says must be replaced ( These should always be
substituted and so should never occur in a query string. [My original query
was aimed at making {wsrp-urlType} one of these but only for default

b) tokens that are opaque to the consumer. Producer can use whatever it
likes here (including doing no substitution).

c) tokens that are booleans. "true" or "false" must be substituted.

d) token that control mode and window state transitions.

e) {wsrp-fragmentID}, {secureURL} and {wsrp-token} (!)

{wsrp-urlType} (a)
{wsrp-url} (a)
{wsrp-portletHandle} (a)
{wsrp-userContextKey} (a)
{wsrp-portletInstanceKey} (a)
{wsrp-sessionID} (a)
{wsrp-navigationalState} (b)
{wsrp-interactionState} (b)
{wsrp-requiresRewrite} (c)
{wsrp-mode} (d)
{wsrp-windowState} (d)
{wsrp-secureURL} (e)
{wsrp-fragmentID} (e)
{wsrp-token} (e)

Only (d) and (e) are likely to cause (very minor) problems so we should not
impact the other types.

My preference would be to only clarify that (d) can use {wsrp-mode} and
{wsrp-windowState} or "" to signal no change is requested. We can introduce
a "null" token (in our namespace) in next version.

(e) is underspecified but allowed by our grammar (10.2.3). Seems safer not
to substitute anything for these.

      -----Original Message-----
      From: Rich Thompson [mailto:richt2@us.ibm.com]
      Sent: 07 November 2003 18:22
      To: wsrp-interop@lists.oasis-open.org
      Subject: [wsrp-interop] Re: [wsrp-conformance] RE: [wsrp-interop]
      follow-up: templates

      I think there are a couple of issues here. First, I think it is
      worthwhile having a value with a semantic meaning that no change in
      mode or windowState is being requested as this eliminates processing
      cycles for the Consumer. What that value should be is an interesting

      The argument in favor of "" is that no mode or windowState will ever
      carry this name and therefore it is a 'safe' value.
      The argument in favor of {wsrp-mode} (or ...) is that it makes the
      querystring (presuming that is where it is in the URL) more readable.

      I think Producers will need a bit of logic that supplies the values
      for whatever the Portlet does not set. If a Producer chooses to
      simply leave tokens like {wsrp-interactionState} in the URL, then the
      Consumer is required to supply that as the interactionState during
      the performBlockingInteraction invocation (and likewise for
      navigationalState). The simplest bit of logic for the Producer would
      be to initialize a set of variables to "" and then provide an
      interface which allows the portlet to set any of them it wants. When
      the URL's string value is being placed into the markup, the Producer
      can simply walk the template and blindly replace the portlet URL
      parameters with their values. While this may make odd looking
      querystrings, I would note they would be valid (and commonly occur


 Andre Kramer                                                              
 11/07/2003 12:14 PM                              wsrp-interop@lists.oasis 
                                                  [wsrp-conformance] RE:   
                                                  follow-up: templates     

      Yes, I favour 3 as it works for unexpected as well as expected {}
      token. Query strings such as ?a=x&b=&c=z look strange so "" does not
      seem a natural choice.

      Also, custom modes & window states are constrained by the values
      negotiated and nav and interaction state are opaque to the consumer.


      -----Original Message-----
      From: Richard Jacob [mailto:richard.jacob@de.ibm.com]
      Sent: 07 November 2003 16:25
      To: wsrp-interop@lists.oasis-open.org
      Cc: wsrp-conformance@lists.oasis-open.org
      Subject: [wsrp-interop] follow-up: templates

      I wanted to add a question on the topic discussed yesterday on both
      about token replacement found in templates (sorry for crossposting):
      Does the producer/portlet need to replace all tokens in a template
      generating URLs?
      I think we said yes but might replace them with empty strings.
      What in the case of {wsrp-mode} or {wsrp-windowState}? For example a
      template like: http://bla.com/here?mode={wsrp-mode}&ws

      I see the follwing options here:
      1. producer replaces with the mode it wants to "change" to (might be
      current mode), could be one of the valid wsrp-modes or a custom-mode
      2. producer replaces with "" (blank), like suggested in yesterdays
      In this case we have an interpretation-issue on the consumer side
      processing these URLs.
      Does a "" mode name mean a mode name containing of an empty string?
      In this
      case the conumer might not know this mode (abviously) and map it to
      Or does a "" mode mean, no change requested, stay in current mode?
      second one seems to be what the portlet wants in that case.
      3. producer does not replace at all
      Here the consumer needs to check while processing the URL that the
      {wsrp-mode} was a template-non-change and interpret this as "stay in
      current mode".

      2 & 3 imply that "" and "{wsrp-mode}" are reserved mode strings and
      are not
      allow to use for mode names (don't think one would ever want to name
      that way :-) )

      I think 1 is the cleanest one, others seem to impose various

      It seems that the Citrix Producer chooses 3. for all replacement
      tokens in
      templates in such cases?

      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

      To unsubscribe from this mailing list (and be removed from the roster
      of the OASIS TC), go to

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]