[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Clearification: Resource URLs and markup params, etc.
Rich, Thanks; Thats explains subtleties. Regards, Wesley Rich Thompson wrote: > > Good questions! > > 1. The difference in language you note was decided on (this was one of > the more protracted discussions around conformance language ...) based > on the difference in the Consumer processing required to approve the > request. Both strongly encourage approval, but the windowState > language recognizes reasons for denial might not be exceptional (e.g. > overall page integrity plays a role). > > 2. You are right that the real thing is having MarkupParams always > contain the actual value after the Consumer has processed any request > to change a mode or windowState value. I also tend to agree that some > reference to the actual semantics in 10.2.1.5 and 10.2.1.6 would be > useful. This is orthogonal to the question of whether the semantics of > getResource preclude even requesting a mode or windowState change ... > > Rich > > > *Wesley Budziwojski <wesley.budziwojski@Sun.COM>* > > 02/22/06 06:06 PM > > > To > Rich Thompson/Watson/IBM@IBMUS > cc > WSRP TC <wsrp@lists.oasis-open.org> > Subject > Re: [wsrp] Clearification: Resource URLs and markup params, etc. > > > > > > > > > > I was wondering if you could clarify; > > 1)Mode/state > It seems that request and change of both wsrp-mode and > wsrp-windowState are intended to happen in the same fashion that is > Porlet requests a change, consumer MUST honor it (unless exception), > consumer reflects status in markup param? > However wording in respective sections is slightly different: > > "consumer MUST respect requests to change the mode outside of > exceptional circumstances ()" > "consumer SHOULD choose to respect this request to change the window > state.." > > If indeed the intended behavior was the same the wording should > reflect that. > > > 2) Section10.2.1.5 and 10.2.1.6 > changing mode or windowState param in MarkupParams is secondary thing > IMHO the actual request is to change mode or windowState. > Consumer reflect "acceptance" (or deny if special circumstances arose) > of the request by submitting proper params? > > Those sections have references to 6.9/6.10 but only in context of > allowable selection. > Making a general reference in terms of actual semantics of > request/change would be useful IMO particularly for the reader who > jumped to this section without reviewing 6.0 > > Thanks, > Wesley > > Rich Thompson wrote: > > I think one must examine the meaning of the portlet url parameters > before attempting to assign meaning for potential new uses. In the > case of wsrp-mode, the meaning is defined in 10.2.1.5 as "a request to > change the mode parameter in MarkupParams into the mode specified as > the value for this portlet URL parameter". Section 6.9 discusses how > the mode parameter describes the Consumer is management of the > End-User's interactions with the Portlet and that all the Portlet can > do is request changes related to this management. Consumer denial of > the request is limited to "exceptional circumstances" with a provided > example of "access control restrictions". What I am hearing on this > email thread is that people view processing a resource URL as another > such example as the semantics of a resource URL do not provide an > opportunity for the Consumer to adjust how it is managing the > Portlet's markup. > > Of course there are implementation choices which allow the Consumer to > impact the larger page as part of a URL activation, but I would argue > there is a semantic mismatch between those implementation choices and > what the spec defines for a resource URL. Rather than attempting a > force fit of the semantics, I would encourage exploring whether those > choices aren't actually extending the getMarkup semantics to include > partial page updates. I suspect that is a better semantic match and it > explicitly recognizes that the protocol is being extended by the > implementation. > > Rich > > *Subbu Allamaraju <**_subbu@bea.com_* <mailto:subbu@bea.com>*>* > > 02/21/06 10:34 PM > > > To > WSRP TC <_wsrp@lists.oasis-open.org_ <mailto:wsrp@lists.oasis-open.org>> > cc > > Subject > Re: [wsrp] Clearification: Resource URLs and markup params, etc. > > > > > > > > > > > > Interesting. I have not noticed this till you pointed it out. > > What does it then mean to supply windowState and mode params with > getResource requests? To keep these symmetric, we should include these > params for resource URLs, and specify that these parameters do not > indicate a mode/window state change, but only apply to the current > request? > > Subbu > > Michael Freedman wrote: > > FYI I had recently checked this: > > Section 10.2.1.5 and 10.2.1.6 are very explicit about where wsrp_mode > > and window_state are valid: > > > > The wsrp-mode portlet URL parameter MAY be used whenever the > > wsrp-urlType portlet URL parameter has a value of “blockingAction” or > > “render”. > > > > The wsrp-windowState portlet URL parameter MAY be used whenever the > > wsrp-urlType portlet URL parameter has a value of “blockingAction” or > > “render”. > > > > -Mike- > > > > Richard Jacob wrote: > > > >> What also strikes me in this context is that we seem to be > ambigeous when > >> we're reusing our structures / url-rewrite-tokens. > >> I think we should have a more crisp definition on which structure > >> elements/members sense (or are even allowed) for which operation. > >> I would argue that this significantly helps developers in > >> understanding and > >> implementing the same protocol without the possibility to > (mis-)interpret > >> the spec in different ways. > >> So it's a tradeoff between protocol flexibility and protocol clarity. > >> One example here is the reuse of markupContext with getResource(). I > >> don't > >> think that setting a new portlet title makes sense when delivering a > >> resource if we agree on Rich's semantical differentiation between > >> getMarkup() and getResource() - and I have the sense that we probably > >> have. > >> The same issue is the window state and portlet mode in resource URLs. > >> > >> Reviewing chapter 10 it striked me that we don't clearly describe > >> which url > >> parameters are allowed for which url-type (example wsrp-url in action > >> URLs > >> makes definitly no sense). > >> I would therefor mandate to rewrite the BNF of our URL formats to > clearly > >> denote which url params can be used for which url-type. Also I would > >> suggest to use BNF notation to denote mandatory and optional > parameters. > >> I think this would also help developers to understand the semantics of > >> the > >> URLs and their according operations better. > >> > >> 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_ > >> > >> > >> > >> Rich > >> Thompson > >> <_richt2@us.ibm.co_ <mailto:richt2@us.ibm.co> > >> m> > >> To WSRP TC > >> <_wsrp@lists.oasis-open.org_ <mailto:wsrp@lists.oasis-open.org>> > 02/21/06 05:21 > >> PM cc > >> > >> > >> Subject Re: [wsrp] > >> Clearification: Resource URLs > >> and markup params, etc. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> I agree with your general comments; Without having spent much time > >> reviewing this phrasing, I would think the clarifications would look > >> something like: > >> > >> - (6.1.13 - MarkupResponse): Since the MarkupContext structure could > >> provide a new sessionID after the Consumer has begun sending the > page to > >> the End-User, special handling is required in order to not lose state > >> related to the new session. Even for stateless Consumers, there are > >> techniques to properly handle this issue (e.g. HTTP cookies). > >> > >> - (6.2 - getMarkup): This operation's semantics are that the > Consumer is > >> aggregating a page which includes the Portlet's markup. > >> > >> - (6.3 - getResource): This operation's semantics are that the > client has > >> requested additional information in a manner that utilized the > >> Consumer as > >> a proxy for supplying that information. > >> > >> Rich > >> > >> > >> Subbu > >> Allamaraju > >> <_subbu@bea.com_ <mailto:subbu@bea.com>> > >> > >> > >> To 02/21/06 10:12 AM Rich > >> Thompson/Watson/IBM@IBMUS > >> > >> cc WSRP > >> TC > >> <_wsrp@lists.oasis-open.org_ <mailto:wsrp@lists.oasis-open.org>> > >> > >> Subject Re: [wsrp] > >> Clearification: > >> Resource URLs and markup params, > >> > >> etc. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >>> As to session, I agree that getMarkup already introduces the > problem of > >>> a late notification that a new session now exists. What would people > >>> think about adding text to 6.1.13 (MarkupResponse definition) > describing > >>> how a stateless Consumer would need to write any new session > information > >>> to a cookie since it is likely too late to place that information onto > >>> all URLs within the page (I suppose the other option is to require > >>> Consumer URL rewriting and delay all rewriting until responses > have been > >>> received from all Portlets ... I would not favor describing this > option > >>> in the spec)? > >>> > >> > >> > >> Instead of mentioning specific implementation choices, how about > >> highlighting the fact that consumers must be ready to honor sessionID > >> changes getMarkup and getResource so that they can provide meaningful > >> user experience? > >> > >> > >> > >>> Just to not loose potential spec changes suggested so far (does this > >>> list miss any??): > >>> > >>> 1. Clarify difference in the semantics of getMarkup and getResource: > >>> Consumer request related to page aggregation vs client request > >>> related to need for additional information. > >>> > >> > >> > >> In principle, I agree, but would not want to make statements that limit > >> the use of getResource to static resources, or such requests to be > >> always driven by client requests after markup generation. The consumer > >> may want to pre-fetch resources. > >> > >> > >> > >>> 2. Add sentence(s) to MarkupResponse.sessionContext (6.1.13) > >>> describing how a stateless Consumer can handle such late knowledge > >>> of a new Portlet session. > >>> > >> > >> > >> Agreed. > >> > >> > >> > >>> 3. 6.9/6.10 should note that HandleEventsResponse can also return > >>> newMode and newWindowState (see above quote from 6.9). > >>> > >> > >> > >> Agreed. > >> > >> Subbu > >> > >> > >> > >> > >> > >>> *Richard Jacob <_richard.jacob@de.ibm.com_ > <mailto:richard.jacob@de.ibm.com>>* > >>> > >>> 02/21/06 06:04 AM > >>> > >>> > >>> To > >>> Subbu Allamaraju <_subbu@bea.com_ <mailto:subbu@bea.com>> > >>> cc > >>> WSRP TC <_wsrp@lists.oasis-open.org_ > <mailto:wsrp@lists.oasis-open.org>> > >>> Subject > >>> Re: [wsrp] Clearification: Resource URLs and markup > >>> > >> > >> params, etc. > >> > >> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Subbu Allamaraju <_subbu@bea.com_ <mailto:subbu@bea.com>> wrote on > 02/21/2006 05:50:37 AM: > >>> > >>> > > - wsrp-mode and wsrp-windowState portlet url parameters. I > >>> > >> > >> would > >> > >> > >>> > > note the descriptions of these explicitly state that they apply to > >>> > > render and blockingAction urlTypes. I think maintaining the > >>> > >> > >> integrity > >> > >> > >>> of > >>> > > the aggregated page requires that these not be supported on > resource > >>> > > URLs, unless someone can point out how a Consumer's decorations > >>> > >> > >> could > >> > >> > >>> be > >>> > > changed or how it would actually place a Portlet into maximize > >>> > > windowState as a result of a resource URL activation. > >>> > > >>> > My interpretation is that, these parameters apply to the portlet > >>> > processing the request, and not necessarily to the consumer applying > >>> > decorations to the markup returned. When a URL contains a parameter > >>> > >> > >> with > >> > >> > >>> > a specific window state, the consumer is merely asking the > producer to > >>> > generate markup or resource reflecting that window state. I > don't see > >>> > >> > >> a > >> > >> > >>> > requirement in the spec to change the window state or mode of the > >>> > portlet, although that's what typical portal-consumers may do. > >>> > > >>> huh? > >>> We explicitly say that an URL invocation of a render/pbia URL includes > >>> > >> > >> the > >> > >> > >>> request to change the mode/window state. > >>> Therefor I would say the contrary: Consumers should honor this (or be > >>> strongly advised to do so) otherwise > >>> the user experience will suffer. It seems strange for me to ignore the > >>> request. I mean we're trying to define a common aggregated UI behavior > >>> > >> > >> and > >> > >> > >>> this certainly contradicts it. > >>> > >>> > > - title: This is another case of the Portlet having > >>> > >> > >> opportunity > >> > >> > >>> > > to impact the Consumer generated portion of the page during page > >>> > > aggregation and therefore doesn't apply to resource url processing > >>> > > >>> > I think, this interpretation is specific to what the consumer is > doing > >>> > with the markup or resource. If the consumer is aggregating the > >>> > >> > >> response > >> > >> > >>> > into a page that has windows-like titlebars, it might use the > title in > >>> > the manner you suggest. Other usages of this field are possible. For > >>> > example, a special purpose consumer may be displaying resources in > >>> > >> > >> popup > >> > >> > >>> > browser windows, and use the title in the browser title bar. > >>> > > >>> > > - sessionID: I am willing to debate this one as I can see a > >>> > > number of good use cases for the Portlet returning a new session, > >>> > >> > >> but > >> > >> > >>> > > how a stateless Consumer could handle it is important. > >>> > > >>> > I agree that the stateless consumer use cases break down with > >>> > >> > >> sessionID > >> > >> > >>> > returned from getMarkup or getResource. As Mike points out, we have > >>> > >> > >> this > >> > >> > >>> > problem with getMarkup itself. > >>> > > >>> > > In summary, perhaps we need to more explicitly state the semantic > >>> > > difference between these operations. Do people generally agree > with > >>> > >> > >> the > >> > >> > >>> > > semantics I have described above? Do people have other proposals > >>> > >> > >> which > >> > >> > >>> > > keep the stateless Consumer supported? Are people willing to throw > >>> > >> > >> out > >> > >> > >>> > > the stateless Consumer design point statements? > >>> > > >>> > Is it impossible to keep the consumer stateless? Perhaps not. To be > >>> > truely stateless, consumer can't just push various pieces of state > >>> > >> > >> into > >> > >> > >>> > the markup when the page is getting generated on the server side and > >>> > expect the state to ramain constant. > >>> I think currently they can because the render result is a result > of the > >>> Consumer processing. Therefor the Consumer has the control. > >>> > >>> > IMO, consumers will have to rely on > >>> > browser side gimmicks to support state updates that happen after the > >>> > page aggregation started (with getMarkup), or even much later (with > >>> > getResource). > >>> Well, things brings us again to AJAX style. > >>> But this breaks the "rule" that the Cosumer is in control and that the > >>> > >> > >> page > >> > >> > >>> state is opaque/mainted by the consumer. > >>> Now you seem to imply that portlets/resources can manipulate the > overall > >>> page state. I think this isn't true with what WSRP defines today > and to > >>> enable that we would need to drop some level of opaqueness of the > >>> overall > >>> state. > >>> > >>> > > >>> > Subbu > >>> > > >>> > > > >>> > > Rich > >>> > > > >>> > > > >>> > > *Subbu Allamaraju <_subbu@bea.com_ <mailto:subbu@bea.com>>* > >>> > > > >>> > > 02/15/06 11:48 AM > >>> > > > >>> > > > >>> > > To > >>> > > WSRP TC <_wsrp@lists.oasis-open.org_ > <mailto:wsrp@lists.oasis-open.org>> > >>> > > cc > >>> > > > >>> > > Subject > >>> > > Re: [wsrp] Clearification: Resource URLs and markup params, etc. > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > The issue of a producer returning two sessionIDs in parallel > >>> > >> > >> requests > >> > >> > >>> is > >>> > > possible, and I don't know if the spec can help either the > consumer > >>> > >> > >> or > >> > >> > >>> > > the producer. > >>> > > > >>> > > One way of avoiding returning new sessionIDs is to somehow tie > >>> > > initCookie with sessionIDs, and raise InvalidCookie fault when > there > >>> > >> > >> is > >> > >> > >>> > > a need to return new sessionID. It is possible to design a > producer > >>> > >> > >> to > >> > >> > >>> > > tie init cookies to sessions, and never return sessionIDs. > >>> > > > >>> > > We have had a number of discussions on this topic in the past, and > >>> > >> > >> the > >> > >> > >>> > > solutions are not always pretty. > >>> > > > >>> > > Subbu > >>> > > > >>> > > Stefan Hepper wrote: > >>> > > > > >>> > > > Subbu Allamaraju wrote: > >>> > > >> On the question of modes and states, I don't see why a portlet > >>> should > >>> > > >> not specify mode and window state params on a resource URL. The > >>> > > >> resource generated may depend on the window state and mode. > >>> > > >> > >>> > > >> The real question is whether the mode and window state > specified > >>> > >> > >> in > >> > >> > >>> a > >>> > > >> resource URL applies to subsequent getMarkup/pbia/he calls or > >>> > >> > >> not. > >> > >> > >>> > > >> The spec leaves this open. It also leaves the same question > open > >>> for > >>> > > >> normal action and render URLs. > >>> > > >> > >>> > > > > >>> > > > right, I think that needs to be clearified. > >>> > > > > >>> > > >> On your point on session, the question is not whether a portlet > >>> > >> > >> can > >> > >> > >>> > > >> return a new sessionID or not, but how it relates to the > >>> > >> > >> sessionID > >> > >> > >>> > > >> returned via a getMarkup/pbia/he. If a producer chooses to > >>> > >> > >> return a > >> > >> > >>> > > >> new sessionID, I would expect the consumer to use that in > >>> subsequent > >>> > > >> calls. This is because, from the consumer's point, getResource > >>> > >> > >> is > >> > >> > >>> just > >>> > > >> another request for a portlet. > >>> > > >> > >>> > > >> I can see at least one use case for returning a new sessionID. > >>> > >> > >> That > >> > >> > >>> is > >>> > > >> when a portlet is generating the resource, e.g. to generate > some > >>> > > >> response for an Ajax request. It should be able to create new > >>> session > >>> > > >> either when there is no session currently, or when the current > >>> session > >>> > > >> expired. > >>> > > >> > >>> > > > > >>> > > > what happens if you make a parallel render call in that case? > >>> Shouldn't > >>> > > > the spec that in that case that the session id returned by both > >>> calls > >>> > > > must be the same (like in the JSR 168 case where different > >>> > >> > >> portlets > >> > >> > >>> of > >>> > > > the same web app can create a new session in parallel at render > >>> time)? > >>> > > > > >>> > > >> On the question of title, my interpretation is that the title > >>> returned > >>> > > >> via any operation applies to the current markup returned, > and it > >>> > >> > >> is > >> > >> > >>> up > >>> > > >> to the consumer to treat it as a new title replacing the > current > >>> one, > >>> > > >> or use it just for that rendition of the markup/resource. So, I > >>> don't > >>> > > >> an issue. > >>> > > >> > >>> > > > > >>> > > > Still sounds confusing to me that the spec states for title: > >>> > > > " The title the Portlet would prefer to be used in any > decoration > >>> > >> > >> of > >> > >> > >>> the > >>> > > > markup." > >>> > > > what are decorations for resources? > >>> > > > > >>> > > > Stefan > >>> > > > > >>> > > >> Subbu > >>> > > >> > >>> > > >> Stefan Hepper wrote: > >>> > > >>> Subbu Allamaraju wrote: > >>> > > >>>> Stefan Hepper wrote: > >>> > > >>>>> I've some questions regarding the resource URLs. From the > >>> current > >>> > > >>>>> version of the spec it is not clear to me how > getResource and > >>> > > >>>>> getMarkup relate to each other. > >>> > > >>>>> - What happens if I specific new nav params, new portlet > mode > >>> > >> > >> / > >> > >> > >>> > > >>>>> window state on the resource URL? Will they be valid for the > >>> next > >>> > > >>>>> getMarkup call? > >>> > > >>>> > >>> > > >>>> Should they be? I think the semantics are the same as that of > >>> > >> > >> a > >> > >> > >>> > > >>>> render URL. > >>> > > >>> > >>> > > >>> Depends if we say that getResource and getMarkup are > related or > >>> not. > >>> > > >>> I think they they should be related and that there should be > >>> > >> > >> only > >> > >> > >>> one > >>> > > >>> set of portlet mode, window state, nav params, per POP. I also > >>> think > >>> > > >>> that we should not allow a resource URL to change this state, > >>> > >> > >> that > >> > >> > >>> > > >>> doesn't make sense to me. > >>> > > >>> > >>> > > >>>> > >>> > > >>>>> - What are the semantics for portlet mode and window state > >>> > >> > >> when > >> > >> > >>> > > >>>>> rendering a resource? What portlet mode and window state > will > >>> the > >>> > > >>>>> portlet receive if nothing is specified? > >>> > > >>>> > >>> > > >>>> I would assume that this is up to the resource handler or the > >>> > > >>>> producer or portlet. > >>> > > >>>> > >>> > > >>> > >>> > > >>> You mean that the result may be different per mode or window > >>> state? I > >>> > > >>> can see use cases for this, but think that the spec should > >>> > >> > >> state > >> > >> > >>> that > >>> > > >>> the getResource calls gets the current portlet mode and window > >>> state. > >>> > > >>> > >>> > > >>>>> - Can you specify navigational state on a resource URL? (yes > >>> > >> > >> I > >> > >> > >>> > > >>>>> assume based on the current spec) > >>> > > >>>> > >>> > > >>>> Yes > >>> > > >>>> > >>> > > >>>>> - Why can the getResource call create a new session? > >>> > > >>>> > >>> > > >>>> It might, if the consumer does not include the current > >>> > >> > >> sessionID. > >> > >> > >>> > > >>>> > >>> > > >>> > >>> > > >>> Why would a getResource call need to create a session? What > >>> > >> > >> would > >> > >> > >>> be > >>> > > >>> the use case? > >>> > > >>> > >>> > > >>>> Could you elaborate on why you think getResource and > getMarkup > >>> are > >>> > > >>>> not related. As far as the context provided by the > consumer is > >>> > > >>>> concerned, they are similar. The only difference is on the > >>> semantics > >>> > > >>>> of the response. > >>> > > >>>> > >>> > > >>> > >>> > > >>> When reading the spec again I could not find a sentence saying > >>> that > >>> > > >>> they are related. I think this needs to be clarified. > >>> > > >>> > >>> > > >>> Another thing I noted is that the getResource operation is > >>> > >> > >> allowed > >> > >> > >>> to > >>> > > >>> change the portlet title. I think that does not really make > >>> > >> > >> sense. > >> > >> > >>> > > >>> What is the use case for allowing to change the title in > >>> getResource? > >>> > > >>> > >>> > > >>> Stefan > >>> > > >>> > >>> > > >>>> Subbu > >>> > > >>>> > >>> > > >>>> > >>> > > >>> > >>> > > >>> > >>> > > >>> > >>> > > >>> > >>> --------------------------------------------------------------------- > >>> > > >>> 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_ > >>> > > >> > >>> > > >> > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> --------------------------------------------------------------------- > >>> > > > 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_ > >> > >> > >>> > > > >>> > > > >>> > > > >>> > >> > >> --------------------------------------------------------------------- > >> > >> > >>> 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_ > >>> > > >>> > >>> > >>> --------------------------------------------------------------------- > >>> 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_ > >>> > >> > >> > >> > >> > --------------------------------------------------------------------- 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_ > >> > >> > > > > --------------------------------------------------------------------- > > 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_ > > > --------------------------------------------------------------------- > 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]