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
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
>> m>
>> To
WSRP
TC
>> <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>
>>
>>
>> To 02/21/06 10:12 AM
Rich
>> Thompson/Watson/IBM@IBMUS
>>
>> cc
WSRP
>> TC
>> <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>*
>>>
>>> 02/21/06 06:04 AM
>>>
>>>
>>> To
>>> Subbu
Allamaraju <subbu@bea.com>
>>> cc
>>> WSRP
TC <wsrp@lists.oasis-open.org>
>>> Subject
>>> Re:
[wsrp] Clearification: Resource URLs and markup
>>>
>>
>> params, etc.
>>
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Subbu Allamaraju <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>*
>>> > >
>>> > > 02/15/06 11:48 AM
>>> > >
>>> > >
>>> > > To
>>> > > WSRP TC <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
|