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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

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


Subject: Re: [wsbpel] Issue - 280 - discussion


Hi Alex,

this keepSrcElementName attribute is really very odd. What's the result of
the following assign if both variables are element-typed and the element
QNames are not equal?

<assign validate="yes">    <copy keepSrcElementName="yes">       <from
variable="var1"/>      <to variable="var2"/>   </copy>
</assign>

Doesn't this ALWAYS result in the bpel:invalidVariables fault?

For a second example how odd this attribute is, assume there's no
validate="yes" on that assign, but in another activity after that assign
there's a XPath query/expression into var2. I assume the XPath
query/expression is written by the modeller upon the assumption that the
content of the variable is the one as declared. So the XPath
query/expression will result in a fault. Additionally, this fact makes it
impossible for a static analysis tool to validate any XPath
queries/expressions in a BPEL 2.0 process (Btw. that would be one of the
cases where BPEL 2.0 is not backwards-compatible with BPEL 1.1 where such
checks were possible ;-)

IMO, this attribute is the only reason why we currently need a catch logic
based on the concrete fault data type and not on the declared data type of
the thrown variable, right? I would prefer to change the catch logic to
QName matching based on the declared data type of the thrown variable and
remove the attribute keepSrcElementName from <copy>. In addition, the catch
logic for elements then would be consistent with the logic for rule 2 and
5. But I think such changes should be subject of another issue.

So when catching types, the logic should be as equal as possible to that
what we already have when catching elements. This still means, the existing
catch rules 1 and 4 would be sufficient, as outlined by Dieter. No
additional rule nor a change at the existing rules would be needed (and too
no clarification, I think). For the following example, you've send it some
notes ago, this would mean that the second <catch> gets it.

Example #2
---------------------------
<scope>  ...  <catch faultType="foo:addressType"> ... </catch>   <catch
faultType="foo:usAddressType"> ... </catch>   ...  <variable name="addrVar"
type="foo:addressType" />  <variable name="usAddrVar"
type="foo:usAddressType" />  ...  <assign>    <copy>       <from
variable="usAddrVar"/>       <to variable="addrVar"
/>     </copy>  </assign>  ...  <throw name="throw1"
faultVariable="addrVar" />
</scope>
---------------------------

Best regards/Mit freundlichen Grüßen,

       Thomas Schulze



                                                                           
             Alex Yiu                                                      
             <alex.yiu@oracle.                                             
             com>                                                       To 
                                       Thomas Schulze/Germany/IBM@IBMDE    
             30.05.2006 23:37                                           cc 
                                       Dieter Koenig1/Germany/IBM@IBMDE,   
                                       Mark Ford                           
                                       <mark.ford@active-endpoints.com>,   
                                       wsbpel@lists.oasis-open.org, Alex   
                                       Yiu <alex.yiu@oracle.com>           
                                                                   Subject 
                                       Re: [wsbpel] Issue - 280 -          
                                       discussion                          
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





Hi Thomas,

[a]
Regardless whether we want to support faultType in BPEL 2.0, you mentioned
another good corner case that we need to clarify - i.e. when element
variable contains an element data which is NOT identical to the element
QName used in variable declaration. (similar to Mark's case)

E.g.:
---------------------
<scope>    ...     <catch faultVariable="myFaultVar" 
faultElement="foo:bar"> ... </catch>     ...     <variable name="var1"
element="foo:bar" />     ...     <assign>          <copy
keepSrcElementName="yes">               <from>
<literal>                        <foo:bar2> ...
</foo:bar2>                   </literal>               </from>
<to variable="var1" />          </copy>      </assign>      <throw
faultVariable="var1" />      ...  </scope>
---------------------

Will the <catch> be activated?

I tend to say the answer is no.

If that is consensus among us, I would provide some more text to tighten it
up.

[b]
Well ... I am not going to repeat myself that much ... But, again ... I see
SubstitutionGroup based matching is 20% usecase, while general schema type
inheritance matching is 80% case of faultType feature.

"adding attributes to enable inheritance matching" in BPEL 3.0 and forcing
users to learn that new attribute for the 80% usecase is something that I
do not prefer. :-) ... I guess the technical reality is a bit clearer now.
But, it is a relatively subjective judgement call on whether we want to
sacrifice future standard usability in order to standardize a 20% usecase
in 2.0.

Thanks!


Regards,
Alex Yiu


Thomas Schulze wrote:
      Hi Alex,

      I agree with you regarding the odd cases (your examples 1 and 2), but
      I
      think we already have them with elements, see my example in the
      previous
      note (matching to your example 1) and the following (your example 2
      slightly modified, matching to your example 2):

      <scope></catch> </catch> element="foo:addressTypeElement"
      />element="foo:usAddressTypeElement" />          <from
      variable="usAddrVar"/> /> faultVariable="addrVar" />
      </scope>

      Because of QName matching and the default for keepSrcElementName="no"
      the
      first catch is selected and not the second, right? Only when changing
      to
      keepSrcElementName="yes" the second catch is selected, or the first,
      too?
      So this is odd, too. In any cases, the user needs to know what he is
      doing.
      In case when using elements and in case when using types.

      Regarding backwards compatibility. I hope a future version of the
      spec will
      put that much priority on backwards compatibility as you propose it
      ;-) The
      most specifications I know haven't done that. That's why I really
      like your
      proposal adding attributes to enable inheritance matching for a
      specific
      <catch> ;-)

      Best regards/Mit freundlichen Grüßen,

             Thomas




                   Alex Yiu

                   <alex.yiu@oracle.

                   com>
      To
                                             Thomas
      Schulze/Germany/IBM@IBMDE
                   30.05.2006 11:41
      cc
                                             Mark Ford


      <mark.ford@active-endpoints.com>,
                                             Dieter
      Koenig1/Germany/IBM@IBMDE,
                                             wsbpel@lists.oasis-open.org,
      Alex
                                             Yiu <alex.yiu@oracle.com>


      Subject
                                             Re: [wsbpel] Issue - 280 -

                                             discussion












      Hi Thomas,

      See comments inline:

      Thomas Schulze wrote:
            Hi Mark and Alex,

            I read all existing fault handling rules as Alex, QName
      matching
            based on
            the declaration in the WSDL. If the actual thrown element
      data's
            QName does
            not match the QName in a <catch faultElement="..."> it isn't
      catched
            by
            that <catch>. IMO, in the following example the <catch>
      currently
            can't
            catch the thrown variable and that's too true for rules 2 and
      5:

            <element name="E1" type="T"/>
            <element name="E2" type="T"/>

            <variable name="E1" element="E1"/>
            <variable name="E2" element="E2"/>

            scope
                catch faultElement="E1"
                ...
                throw variable="E2"

            Means there is currently no support for cross-over catching
      (elements
            of
            the same type) or substitution groups. Maybe this needs a
            clarification.


      [AYIU]: [a] I hope my suggested additional text that I just sent out
      is
      good enough to plug the holes and cure any ambiguity.


            But exactly that's the reason why we propose to resolve issue
      280 by
            only
            adding a faultType attribute to <catch> and do the matching by
      QName
            according to the current rules 1 and 4. Like for elements, no
      support
            for
            inheritance and cross-over catching. Currently no type-matching
      is
            supported and with this proposal we don't like to change that
      when
            resolving this bug issue which only addresses the existing
            inconsistency
            between <throw> and <catch>.
            For me, catching types is not only a 20% usecase. It's more a
      50%
            usecase,
            I think. The current spec makes extensive use of examples with
            multi-part
            messages which parts are type-typed. And there are too a lot of
            existing
            WebServices which have an interface with such messages. To be
      able to
            support those existing stuff fully, I think BPEL needs to be
      able to
            throw
            and catch types. As outlined in section 3 BPEL is open to
      support all
            kinds
            of WebServices and does not only concentrate on specific other
            specifications.


      [AYIU]: [b] I totally understand there are some values in adding
      support
      for catching a type-based fault. But, it is still a judgment call
      between
      the values of features and its complexities and risk of delaying the
      spec
      and blocking future spec evolution. (See more below)

            Alex, regarding "... make it difficult for future BPEL standard
      to
            support
            a richer semantics similar to the type-matching example above
      without
            breaking backward compatibilities.":
            When we decide to solve the bug by adding the possibility to
      catch
            types,
            this will be part of rule 1 and 4. In a future BPEL standard,
      rule 1
            and 4
            will still be the first rules which have to be considered first
      for
            all
            catch blocks. This means a <catch> which catches a type today
      will
            catch it
            too in the future, because new rules have to be added after
      rule 1
            and 4. I
            don't see there any future backwards compatibility problems.
      Far from
            it, I
            think this strict solution makes it easier to extend that in
      the
            future.


      [AYIU]:
      [c]
      Assume we have a <catch faultType="foo:addressType" > and it is
      matched by
      a fault data declared with schema type of the exact QName. Consider
      the
      following:

      Example #1
      ---------------------------
      <scope>...-->
           <variable name="usAddrVar" type="foo:usAddressElem" />on
      foo:usAddressType -->
           ...</scope>
      ---------------------------

      From user viewpoint, it is odd that if the <catch> does not catch the
      fault
      triggered by "throw2". I am sure that will be complaint #1 for our
      users,
      if we put this feature by QName matching only for schema type into
      the
      spec. That would be too different from other programming langauges
      (e.g.
      Java)

      Example #2
      ---------------------------
      <scope></catch> ...name="usAddrVar" type="foo:usAddressType" /><copy>
      variable="addrVar" /> name="throw1" faultVariable="addrVar" />
      </scope>
      ---------------------------

      That is another odd case. Even though the data is of "addrVar" is
      exactly
      of the "usAddressType". But, the <catch> for usAddressType does not
      get
      activated?

      [d]
      About future spec evolution and backward compatibility,
      if BPEL 2.0 spec says:
      <catch faultType="foo:addressType">
      syntax matches the fault variable declared with type of exact QName
      only.
      Then, in BPEL 3.0, we cannot extend its semantics to do inheritance
      matching of the same syntax without breaking any backward
      compatibility.
      Because, if the syntax does not catch certain faults in 2.0 then the
      same
      syntax should not catch any new fault in 3.0.

      At most, we can add a new switch to the syntax, then we can extend
      its
      catching semantics. E.g.:
      <catch faultType="foo:addressType"
      enableSchemaTypeInstanceMatching="yes">

      For faultElement,  when we want to support Subsitution Group in 3.0,
      then
      we will need to add a new attribute. e.g.:
      <catch faultElement="foo:bar" enableSubsitutionGroup="yes">

      I am relatively comfortable with that because SG is not a frequently
      used
      feature in schema.  (Note: in JAXB 1.0, they even did not have SG
      support.)
      Unlike type inheritance, SG has not parallel concepts in other
      programming
      langauges. Developers of other programming languages would not feel
      surprised.

      On the other hand, derived-type are used more frequently in schema
      world
      IMHO. Even if derived type is not used, catching an element-based
      fault
      variable of the same type are still frequently expected. (See example
      #1
      above)

      If we add faultType feature, 80% usecase or users would need
      inheritance or
      "instance-of" typing checking (instead of just exact QName matching).
      And,
      it may not be a good idea to  force users to learn and use a new
      switch in
      BPEL 3.0 in order to enable a 80% usecase, while we try to
      standardize just
      20% usecase of faultType in BPEL 2.0.

      I hope my thinking process makes sense to you guys.
      Thanks!



      Regards,
      Alex Yiu





            Best regards/Mit freundlichen Grüßen,

                   Thomas




                         "Mark Ford"

                         <mark.ford@active

                         -endpoints.com>
            To
                                                   "'Alex Yiu'"
            <alex.yiu@oracle.com>
                         30.05.2006 06:36
            cc
                                                   Dieter
            Koenig1/Germany/IBM@IBMDE,
                                                   Thomas
            Schulze/Germany/IBM@IBMDE,

      <wsbpel@lists.oasis-open.org>


            Subject
                                                   RE: [wsbpel] Issue - 280
      -

                                                   discussion











            The part of the rules that I'm questioning has to do with rule
      #2 and
            #5
            which cover the single element part WSDL message. Do you read
      this to
            say
            that the QName for the element comes from the actual element
      data or
            the
            declaration of the <part element="qname"/> in the WSDL? There
      are
            cases
            where the QNames could be different. It would be possible to
            construct a
            WSDL message variable and populate it with an element for use
      with a
            <throw> that differed from the element QName in the part
      description.
            Perhaps the element used was part of a substitutionGroup or
      perhaps
            it was
            simply user error. In either case, I'd like to clarify which
      QName to
            use
            for the element when matching.

            Here's rule #2 with my emphasis:


            2.      Otherwise if the fault data is a WSDL message type
      where the
            message contains a single part defined by an element and there
      exists
            a
            <catch> construct with a matching faultName value that has a
            faultVariable
            whose associated faultElement’s QName matches the QName of the
            element used
            to define the part then the fault is passed to the identified
      <catch>
            construct with the faultVariable initialized to the value in
      the
            single
            part’s element.


            It seems to me that we're driving this match based on the <part
            element="qname"/> from the WSDL and not from the element data.
      If
            this is
            the intent, then it feels a little inconsistent since in the
      other
            cases
            we're basing the match on the contents of the data as opposed
      to some
            declaration of its type. If this is not the intent, then
      perhaps this
            section could do with a slight rewording to make it more clear?



            From: Alex Yiu [mailto:alex.yiu@oracle.com]
            Sent: Monday, May 29, 2006 9:35 PM
            To: Mark Ford
            Cc: 'Dieter Koenig1'; 'Thomas Schulze';
      wsbpel@lists.oasis-open.org;
            Alex
            Yiu
            Subject: Re: [wsbpel] Issue - 280 - discussion


            Hi Mark,

            Hope you had a good long weekend ... :-)

            I would like to address your question about "ambiguities" of
      the last
            part
            of email.

            The current rule is clear to me that we are doing an exact
      QName
            match.
            That is, substitutionGroup is not considered in the <catch>
      matching
            logic.


            Further elaboration: <catch faultElement="foo:bar"> will catch
      only
            faults
            that is of either element whose exact QName is "foo:bar" or
      message
            type of
            single part of element whose exact QName is "foo:bar". And, it
      will
            NOT
            catch a fault of element "foo:bar2" which is a part of
            substitutionGroup of
            "foo:bar".

            Our current <catch> rule does not touch any XML schema typing
      issue
            at all.
            If in future we are ready to handle XML schema typing in our
      <cach>
            matching rules, we can for sure consider adding support for
            substitutionGroup at <catch> with a switch (that is a 20%
      usecase).

            Back to commenting a bit more on Dieter's proposal: if we had
            introduced
            "faultType", that I would consider it is a 50%~80% of people
      would
            expect
            type-matching, instead of QName matching. That was also what I
            mentioned to
            Yaron back in Fall 2005. Yaron decided not to deal with the
      type
            matching
            problem by not introducing the "faultType" attribute in NY F2F
      (Dec
            2005).

            Thanks!



            Regards,
            Alex Yiu





            Mark Ford wrote:
                  Does your proposal extend to elements as well?
      Specifically,
            should
                  the
                  declared type of the element variable be considered as
      opposed
            to its
                  actual
                  content?

                  I'm not sure if others have interpreted the rules as I
      have but
            my
                  reading
                  is that the Qname of the element content drives the match
            except in
                  the case
                  of a single part WSDL message which relies on the
      declared
            type.

                  Regardless of this issue is resolved, I think we should
      clarify
            the
                  fault
                  matching rules to remove an possible ambiguities. For
      example,
            what
                  would
                  happen if I had a schema that used substitutionGroups and
      threw
            a
                  fault with
                  an element within the substitutionGroup? Would the fault
            matching be
                  driven
                  by the declared type which was the head of the group or
      by the
            actual
                  data
                  which was one of the allowed substitutions?





                  -----Original Message-----
                  From: Dieter Koenig1 [mailto:dieterkoenig@de.ibm.com]
                  Sent: Monday, May 29, 2006 10:00 AM
                  To: alex.yiu@oracle.com; Mark Ford
                  Cc: Thomas Schulze; wsbpel@lists.oasis-open.org
                  Subject: Re: [wsbpel] Issue - 280 - discussion

                  Hi Alex and Mark, rules 1 and 4 should take care of both
            element and
                  type by
                  means of strict QName matching.

                  In other words,
                   - when a variable is defined with a type ns:t then it
      can be
            caught
                  using a
                  faultType that specifies the same QName ns:t
                   - when a variable is defined with an element ns:e then
      it can
            be
                  caught
                  using a faultElement that specifies the same QName ns:e

                  This clarification would need to be added to the two
      rules, and
            the
                  faultType attribute be added to catch.

                  Kind Regards
                  DK


                   Dieter König                                Mail:
                  dieterkoenig@de.ibm.com
                  IBM Deutschland Entwicklung GmbH


                   Senior Technical Staff Member               Tel
      (office):
            (+49)
                  7031-16-3426      Schönaicher Strasse 220


                   Architect, Business Process Choreographer   Fax
      (office):
            (+49)
                  7031-16-4890      71032 Böblingen


                   Member, Technical Expert Council            Tel (home
      office):
            (+49)
                  7032-201464  Germany








                               Alex Yiu

                               <alex.yiu@oracle.

                               com>
                  To
                                                         Mark Ford

                               24.05.2006 19:47
                  <mark.ford@active-endpoints.com>
                  cc
                                                         Thomas
                  Schulze/Germany/IBM@IBMDE,

            wsbpel@lists.oasis-open.org,
                  Alex
                                                         Yiu
            <alex.yiu@oracle.com>


                  Subject
                                                         Re: [wsbpel] Issue
      - 280
            -

                                                         discussion












                  Hi,
                  [ Changing the subject line ... such the issue list can
            "correlate"
                  this
                  email thread ;-) ]

                  Currently, there is a set of rules stated in section
      "12.5
            Fault
                  Handlers"
                  to determine which <catch> will be used during fault
      handling.
                  (under "in the case of faults thrown with associated date
      ...")

                  As Mark stated, if we want to support XSD-type (both
      simple and
                  complex
                  type) in the <catch> clause, we need to modify that set
      of
            rules
                  significantly. There are 6 rules involved in that set.
      They are
            just
                  using
                  element's QName matching and message type's QName
      matching
            there.
                  The passed resolution intentionally avoid any type
            inheritance-based
                  checking there.

                  If we allow simple-type or complex-type based <catch>
      clause,
            it
                  would be
                  odd to some users, if we don't do any type
      inheritance-based
            checking
                  (similar to Java catch). If we do inheritance-based
      checking
            (e.g. a
                  "foo:AddressType" based <catch> can handle a
            "foo:USAddressType"
                  fault), we
                  would wander in the territory of "best-match" schema type
            semantics,
                  which I
                  am not sure any other spec has done that before.

                  If we don't do inheritance-based checking, it may not be
      that
            simple
                  either
                  to resolve all the most appropriate <catch> either. e.g.
      which
            one
                  will be
                  matched?
                  <catch faultType="foo:AddressType">
                  vs <catch faultElement="foo:AddressElem"> (where
            "foo:AddressElem" is
                  based
                  on "foo:AddressType") vs <catch
                  faultMessageType="foo:AddressMsgType">
                  (where "foo:AddressMsgType" has a single part based on
                  "foo:AddressType")

                  I am quite sure if we spend enough time, there will be a
            matching
                  algorithm
                  developed. But, at the same time, the 80-20 rules applies
      here.
            That
                  is, we
                  may need to double the size of rules (from 6 to 12) for a
      20%
                  usecase?
                  Complexity kills usability.

                  Last, it may be too late for this cycle of spec to add
      such a
            new
                  feature to
                  <catch>.


                  I hope my train of thoughts sound reasonable to you guys.
                  Thanks!


                  Regards,
                  Alex Yiu


                  Mark Ford wrote:


                        I think this issue boils down to how we determine
      the
            type of
                        the fault
                        data. The current matching rules match element data
      by
            their
                        QNames.
                        There is a subtle difference with WSDL Message
      fault data
            that
                        define a
                        single part of type element. In this case, the
      QName for
            the
                        fault data
                        comes

                  from

                        the part's element type declaration as opposed to
      the
            actual
                        data for
                        that part.

                        If we add support for type-typed variables, then we
      need
            to
                        change how
                        the type of the fault data is determined. The
      existing
            rules
                        for
                        determining

                  the

                        type of the fault data are insufficient in this
      regard
            because
                        they
                        look only at the element data itself which could be
            ambiguous
                        with
                        complex

                  types

                        and elements.

                        How do you propose to determine the type of the
      fault
            data?


                        -----Original Message-----
                        From: Thomas Schulze [
      mailto:ThomasSchulze@de.ibm.com]
                        Sent: Tuesday, May 23, 2006 1:32 PM
                        To: wsbpel@lists.oasis-open.org
                        Subject: [wsbpel] BPEL Issue 280

                        BPEL Issue 280 addresses an inconsistency between
      BPEL's
                        <throw> and
                        <catch>. While <catch> can only handle
      message-typed and
                        element-typed

                  data,

                        <throw> can additionally throw type-typed data. The
            proposal is
                        to put
                        the restriction on <throw> to be able to throw only
                        message-typed and
                        element-typed data.

                        Before doing this, I would like to discuss the
      other
                        opportunity,
                        allowing <catch> to catch type-typed data.

                        Rationale:
                        The BPEL 2.0 spec builds on WSDL 1.1 which allows
      to have
                        messages with
                        multiple parts. These parts can either be
      element-typed
            or
                        type-typed.
                        For instance, assume the following WSDL message
      (from the
                        initial
                        example in section 5.1):

                        <wsdl:message name="POMessage">
                         <wsdl:part name="customerInfo"
            type="sns:customerInfoType"/>
                         <wsdl:part name="purchaseOrder"
            type="sns:purchaseOrderType"/>

                        </wsdl:message>

                        Besides i.e. receiving such a message in a
      message-typed
                        variable, you
                        can use <fromPart>. This means, you can receive
      this
            message in
                        two
                        type-typed
                        variables:

                        <bpel:variable name="CustomerInfo"
                        type="sns:customerInfoType"/>
                        <bpel:variable name="PurchaseOrder"
                        type="sns:purchaseOrderType"/>

                        <bpel:receive name="ReceivePOMessage"
      partnerLink="..."
                        operation="...">
                         <bpel:fromPart part="customerInfo"
            toVariable="CustomerInfo"/>
                         <bpel:fromPart part="purchaseOrder"
                        toVariable="PurchaseOrder"/>
                        </bpel:receive>

                        Now imagine a process which makes use of only such
            type-typed
                        variables.
                        They never can be thrown when resolving the issue
      as
            proposed.
                        If a

                  modeler

                        of a BPEL process needs to throw such a variable,
      he is            forced
                        to

                  introduce

                        a new message or element making use of that type
      and then
            throw
                        this
                        message-typed or element-typed variable.

                        This problem have already been discussed in Issue
      93
                        (


      http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue93
                        ).
                        The reasoning for not allowing to catch type-typed
      data
            was:
                        "Throwing
                        complex types as faults is vaguely odd and WS-I
      requires
            that
                        all SOAP
                        faults be defined using elements so in general Web
            Services
                        faults are
                        typically elements anyway."

                        I think WS-I does not apply here, because <throw>
      and
            <catch>
                        are BPEL
                        internal constructs. If a BPEL process should
      produce a
            Web
                        Service
                        fault <reply> have to be used. BPEL does not put
      any
                        restrictions on
                        replying a fault. So why on throwing a fault?

                        Additionally remember chapter 8.1: "The infoset for
      a
            complex
                        type

                  variable

                        consists of a DII that contains exactly one child,
      which
            is an
                        EII
                        referenced by the document element property. ...
      However
            the
                        children
                        of

                  the

                        document element MUST exclusively consist of the
      complex
            type
                        values
                        assigned to the variable."
                        Does that mean that type-typed variables have to be
            internally
                        represented as element-typed? (maybe one of the DII
      / EII
            / AII
                        / TII
                        experts can

                  answer

                        that question) If yes, the catch logic shouldn't
      differ
            that
                        much from
                        the existing when allowing to catch type-typed
      data.

                        I appreciate any comments/further thoughts on this.
      Tanks
            in
                        advance!

                        Best regards/Mit freundlichen Grüßen,

                              Thomas Schulze




      ---------------------------------------------------------------------

                        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]