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


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

1, 2, 3a and 3b are all fine.

As I said previously, I prefer 4c, as a producer that does care can chose to do 4a (which I agree is the safest bet for mode navigational links cf your example). However, if you (and Subbu or others) feel strongly that 4b is better then we could make  that the case for wsrp-mode (and even wsrp-windowState).

regards,
Andre

-----Original Message-----
From: Richard Jacob [mailto:richard.jacob@de.ibm.com]
Sent: 11 November 2003 14:38
To: Subbu Allamaraju
Cc: wsrp-interop@lists.oasis-open.org
Subject: Re: [wsrp-interop] Re: [wsrp-conformance] RE: [wsrp-interop]
foll ow-up: templates



Ok, then we're all on the same track, I think.
Let me try to briefly summerize the options we have set up and the
differences that remain:
1. there is a group of tokens which must be replaced by valid values in any
case
2. there is a group of tokens which may not be replaced because a) the
producer/portlet does not want to, does not have the information or is
meaningless in some cases
3. two option for those token which can't be filled with meaningfull
values:
a) portlet/producer leaves the {wsrp-..} token to indicate "not set, don't
bother with it"
b) portlet/producer substitutes {wsrp-..} to "", to indicate "not set,
don't bother with it"
4. what to do with mode and window states?
a) must always be set by the producer/portlet
b) choose option 3a) or 3b) to indicate not set, Consumer interprets as
"stay in same mode/window state"
c) choose option 3a) or 3b) to indicate not set, Consumer interprets as
"don't care, Consumer's decision"

I'm just thinking loud: Consumers must always process URLs and interpret
the various values, it would also need to interpret "" or "{wsrp-...}". So
the consumer couldn't care less? What makes it an advantage for producer's
to activly do the replacement for all tokens (although easily possible
since the producer does the replacing for some of them anyway). I think I
don't see an advantage here therefor could happily live with 3a).

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


|---------+---------------------------->
|         |           Subbu Allamaraju |
|         |           <subbu@bea.com>  |
|         |                            |
|         |           11/11/2003 03:03 |
|         |           PM               |
|---------+---------------------------->
  >--------------------------------------------------------------------------------------------------------------------------------------------------|

  |                                                                                                                                                  |

  |       To:       wsrp-interop@lists.oasis-open.org                                                                                                |

  |       cc:                                                                                                                                        |

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

  >--------------------------------------------------------------------------------------------------------------------------------------------------|




Richard,

By removing, I meant to replace with an empty string, and the rules are:

{wsrp-urlType} - always replaced
{wsrp-url} - replaced for resource URLs. Remove for other templates.
{wsrp-portletHandle} - always replaced
{wsrp-userContextKey} - always replaced
{wsrp-portletInstanceKey} - replaced if known, removed otherwise
{wsrp-sessionID} - replaced is there is a session, removed otherwise
{wsrp-navigationalState} - replaced with navigational state, removed if
there is no state
{wsrp-interactionState} - replaced with interaction state, removed if
there is no state
{wsrp-requiresRewrite} - replaced with a true or false in resource URLs.
Removed in other URLs
{wsrp-mode} - replaced with current or new values. Removed from resource
URLs (?)
{wsrp-windowState} - replaced with current or new values. Removed from
resource URLs (?)
{wsrp-secureURL} - replaced with true or false
{wsrp-fragmentID} - replaced if there is a fragment. Removed otherwise

So, in your example, the above rules translate to

http://my.com/portal/anzeigeistgleichblockingAction/neuerZustandentsprichtview/fenstergroessesollteseinmaximized/blabla


when the current mode is "view", window state "maximized", urlType is
blockingAction, and there is no portletInstancekey.

Regards,

Subbu

Richard Jacob said the following on 11/11/2003 02:36 AM:

>Subbu,
>
>by remove you mean replace {wsrp-...} with ""?
>If so, yes this could be an option we were discussing.
>
>If you mean to try to remove the "mode change request" (didn't find a
>better wording here) in the URL then you can't because for the
>producer/portlet all characters outside the {..}-tokens are constants and
>must not be changed.
>Btw. it would be even possible to remove because you don't know what the
>cosumer uses its own constants to mark mode changes in its URLs, it only
>needs the token to be replaced.
>You could also break the consumer's URL.
>Example template:
>http://my.com/portal/anzeigeistgleich{wsrp-urlType}/neuerZustandentspricht{wsrp-mode}/fenstergroessesolltesein{wsrp-windowState}/blabla

>
>{wsrp-portletInstanceKey}
>
>Which of these would you remove?
>
>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
>
>
>|---------+---------------------------->
>|         |           Subbu Allamaraju |
>|         |           <subbu@bea.com>  |
>|         |                            |
>|         |           11/11/2003 04:40 |
>|         |           AM               |
>|---------+---------------------------->
>  >
--------------------------------------------------------------------------------------------------------------------------------------------------|

>  |
|
>  |       To:       wsrp-interop@lists.oasis-open.org
|
>  |       cc:
|
>  |       Subject:  Re: [wsrp-interop] Re: [wsrp-conformance] RE:
[wsrp-interop] foll ow-up: templates
|
>  >
--------------------------------------------------------------------------------------------------------------------------------------------------|

>
>
>
>
>
>Few comments
>
>1. It is fairly trivial for a producer to replace wsrp-mode and
>wsrp-windowState tokens with either new values or current values. I
>would argue against introducing special tokens (such as wsrp:null) or
>replacing with " ", as this would increase the complexity for the
>consumer. If replacing these tokens with current values (when there is
>no transition) is considered risky, why not remove those tokens?
>
>2. For tokens under (a), if the producer is unable to set a value for a
>token it should remove it. An example is wsrp-portletInstanceKey.
>
>To keep the rules simple and easy to understand, why not remove unset
>tokens (I'm excluding (b) and (c))?
>
>Regards,
>
>Subbu
>
>Richard Jacob wrote:
>
>
>
>>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 (10.2.2.9).
>>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 10.2.1.4 and 10.2.1.5 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
>>x.)
>>With that argument it would put a) b) c) d) into one equal group: "MUST
>>replace".
>>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 (10.2.2.9). 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
>>templates.]
>>
>>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.
>>
>>regards,
>>Andre
>>      -----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
>>      question.
>>
>>      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
>>      today).
>>
>>      Rich
>>
>>
>>
>>
>
>
>
>> Andre
>>Kramer
>> <andre.kramer@eu.citrix.com>
>>
>>
>
>
>
>>
>>
>
>
>
>>To
>> 11/07/2003 12:14 PM
>>wsrp-interop@lists.oasis
>>
>>-open.org
>>
>>cc
>>
>>wsrp-conformance@lists.o
>>
>>asis-open.org
>>
>>Subject
>>                                                  [wsrp-conformance]
>>RE:
>>
>>[wsrp-interop]
>>                                                  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.
>>
>>
>>      regards,
>>      Andre
>>
>>
>>      -----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
>>      calls
>>      about token replacement found in templates (sorry for
>>crossposting):
>>      Does the producer/portlet need to replace all tokens in a template
>>      when
>>      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
>>      render
>>      template like: http://bla.com/here?mode={wsrp-mode}&ws
>>      ={wsrp-windowState}....
>>
>>
>>      I see the follwing options here:
>>      1. producer replaces with the mode it wants to "change" to
>>(might be
>>      the
>>      current mode), could be one of the valid wsrp-modes or a
>>custom-mode
>>      2. producer replaces with "" (blank), like suggested in yesterdays
>>      call.
>>      In this case we have an interpretation-issue on the consumer side
>>      when
>>      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
>>      view.
>>      Or does a "" mode mean, no change requested, stay in current mode?
>>      The
>>      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
>>      mode
>>      {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
>>      modes
>>      that way :-) )
>>
>>
>>      I think 1 is the cleanest one, others seem to impose various
>>      interpretation
>>      possibilities.
>>
>>
>>      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
>>
>>
>>
>>
>http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php

>
>
>
>>      .
>>
>>
>>
>>
>>
>>To unsubscribe from this mailing list (and be removed from the roster
>>of the OASIS TC), go to
>>
>>
>>
>http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php

>.
>
>
>
>
>
>To unsubscribe from this mailing list (and be removed from the roster of
>the OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php

>.
>
>
>
>
>
>



To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php
.





To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php.



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