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

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

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


Subject: RE: [sca-assembly] ISSUE 5: Component type allows to specify wire targetson references: PROPOSAL



Folks,

Some comments inline as <mje>  </mje>

Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com



"Peshev, Peter" <peter.peshev@sap.com>

14/03/2008 17:32

To
Graham Charters/UK/IBM@IBMGB
cc
"David Booz" <booz@us.ibm.com>, "Patil, Sanjay" <sanjay.patil@sap.com>, <sca-assembly@lists.oasis-open.org>
Subject
RE: [sca-assembly] ISSUE 5: Component type allows to specify wire targets on references: PROPOSAL





Hi Graham,

IMO if there is another  XML file called componentType which basically duplicates the SCDL configuration in another syntax, and the componentType can serve as SCDL replacement, that's not much of a simplicity , but only brings confusion what is the difference between the two.


<mje>
The simplicity is not having XML at all.

You'll probably get bored with me saying this, but I prefer a situation in which there is *never* any componentType FILE.
The componentType is a notional data structure, ideally completely derived from the contents of the actual implementation
to which it relates.

So the idea of providing suitable annotations to enable the implementation artifact to completely populate the
componentType data structure is in fact in support of this simple concept.
</mje>

Just thinking loudly (I may be ashamed afterwards) ,  for such "quick-n-dirty" usecases that we want to merge the data - how about offering the possibility to define  the componentType tag  (without any configurations, targets,etc.)  inside the SCDL, the configurations should still be done via the existing concept of components & composites,  and adding recommendation that a best practice is to keep them apart as separate artifacts.


<mje>
First, I stand on my soapbox:  This is most certainly NOT "quick-n-dirty".  It is *quick* and it is *simple".

However, using the word "dirty" implies that something incorrect and not to be encouraged is going on here.
Far from it.  An implementation that is fully annotated fits into the wider SCA world beautifully.  It is completely
usable within a composite and can be reconfigured by that composite just in the same way that any implementation
can be reconfigured.

As for keeping the componentType tag within the SCDL - my point is and always has been that the componentType
information should never normally be written down by anyone - it is a notional or virtual data structure extracted from
the implementation.  So combining the componentType into the SCDL make no sense to me at all.

As for doing configurations via composites and components, my proposed approach does not change that at all.
However, I don't regard it as "best practice" to keep things as separate artifacts.  Horses for courses here.
In simple cases, combining all the configuration data in the implementation artifact is the best and simplest
approach.  In other cases, where complex compositions are going on, then there needs to be a suitable
composite file providing appropriate configuration for the components.
</mje>

About the "new annotations for java" route and reusing existing metadata.  First, supplying an SCA target as in the issue 5 text  is hardly existing metadata, that's something that the SCA brought, so we will need new annotation and concept.  While bringing new functionality we should try to keep balance between the existing number of annotations, the overall complexity and decide on case by case basis. When I am looking at the existing 30 annotations in org.osoa.java I am already feeling they are too much already.  Personally, I would be happy to drop some of them (especially some conversational & callback oriented), and add something some like @Reference(defaultTarget="goshko"). But that's a discussion for another TC


<mje>
I can agree that perhaps there are too many existing annotations - a number of which are unique to Java and do not relate to the
Assembly model.  We should take a critical look at them and see what pruning might be possible.

HOWEVER, the suggestion of having Java annotations that correspond to specific concepts that are already in the Assembly
specification is not adding a concept, in my opinion - it is only providing a concrete Java realization of something already
present in SCA.  No-one has to use annotations (other than @Remotable on interfaces, I believe) but if they are targetting
an SCA environment with their Java implementations, then developers may want/need to deal with SCA concepts and i is
valuable for them to be able to express those concepts in Java rather than having to switch to XML.
</mje>
 
Best Regards
Peter



From: Graham Charters [mailto:CHARTERS@uk.ibm.com]
Sent:
Thursday, 13. March 2008 23:25
To:
Peshev, Peter
Cc:
David Booz; Patil, Sanjay; sca-assembly@lists.oasis-open.org
Subject:
RE: [sca-assembly] ISSUE 5: Component type allows to specify wire targets on references: PROPOSAL



Hi Peter, I've added some comments below in <gcc></gcc>



Regards,

Graham.



Graham Charters PhD CEng MBCS CITP
SWG AB Projects
IBM United Kingdom Limited, MP 146, Hursley Park, Winchester, SO21 2JN, UK
Tel:  (Ext) +44-1962-816527     (Int) 7-246527   (Fax) +44-1962-818999
Internet: charters@uk.ibm.com



"Peshev, Peter" <peter.peshev@sap.com> wrote on 13/03/2008 18:53:18:

> Hi Graham,
>  
> Just to make sure I understand, basically you are saying -- SCA is too
> complex to be used by some developers, so let's allow SCA without  SCA
> SCDL artifacts to appease those people by allowing "quick-n-dirty" fully
> configured components. Right ?


<gcc> Partly.  It's not just some developers, it's some scenarios where the flexibility and role distinctions (and how they are burned into the programming model) actually get in the way of them achieving their goal.  There's also the 'mandatory' use of XML as part of that.</gcc>


>  
> If yes, how exactly are you planning to provide this "quick-n-dirty"
> configuration of SCA.
>  -- By componentType side files in XML format, which I would say are
> equally complex  to SCDL-s
>  -- By introducing  introspection rules for different technologies and
> how they could generate the new fully configured componentType. Probably
> that would result to new constructs in the respective implementation
> types (new annotations for java, etc.).


<gcc>I think it's the latter, and I also think that's business-as-usual for SCA.  When defining an implementation type, I think it's good to re-use existing metadata through some existing introspection capability.  Some technologies support this, and some don't, in which case we can describe them with an XML componentType or add some introspection capability to the technology (the C++ spec did this, open source PHP SCA did this, etc...).  We've already gone down the "new annotations for java" route with the SCA Java annotations.</gcc>


>  
> Btw, IMHO  if something went too complex and developers refuse to use it
> , we should simplify it, instead of adding new capabilities and another
> layer of complexity in the specs.
>  


<gcc>I totally agree with the first part, regarding simplifying, what I don't understand is how this is really another layer of complexity.  It follows the SCA model (the definition for services, references, properties, bindings, etc.), it just allows the information to be specified in a single artefact, but still be re-used in a full SCA assembly without having to re-declare everything.  It's up to each implementation type to choose whether they support that approach. </gcc>


> Best Regards
> Peter
>  
> ________________________________
>
> From: Graham Charters [mailto:CHARTERS@uk.ibm.com]
> Sent: Thursday, 13. March 2008 17:16
> To: Patil, Sanjay
> Cc: David Booz; sca-assembly@lists.oasis-open.org
> Subject: RE: [sca-assembly] ISSUE 5: Component type allows to specify
> wire targets on references: PROPOSAL
>
>
>
> Hi Sanjay,
>
> I'm not Dave, or Mike, but I'd like to chip in ;-) .  I think they've
> both covered most of the points I would make, regarding easing adoption
> by making it quick to get started, and the fact that a single person is
> performing multiple roles.  Regarding your questions:
>
> > Question: Why in the world do you need to generate a componentType for
> > this use case of 'directly deploying a fully configured
> implementation'?
> > I thought you wanted to directly deploy a fully configured
> > implementation because pointy brackets may hurt and bleed, right? So
> > just go ahead and deploy the fully configured implementation. Why
> bother
> > about generating a componentType (which would have pointy brackets)?
>
> I think this comes down to how these fully configured implementations
> get re-used and reconfigured in a pointy brackets world.  Mike mentioned
> this in his response about not requiring everything to be redeclared.
>
> I think we have an opportunity here to enable a broader community of
> developers, which can bring skills and build assets to our SOA
> programming model.  If we don't make it a smooth progression from the
> "quick-n-dirty" fully configured world to the world of SCDL, then I
> think we'll be limiting the applicability of SCA, and helping persuade
> the "quick-n-dirty" folks to choose another technology.
>
>
> Regards,
>
> Graham.
>
>
>
> Graham Charters PhD CEng MBCS CITP
> SWG AB Projects
> IBM United Kingdom Limited, MP 146, Hursley Park, Winchester, SO21 2JN,
> UK
> Tel:  (Ext) +44-1962-816527     (Int) 7-246527   (Fax) +44-1962-818999
> Internet: charters@uk.ibm.com
>
>
> "Patil, Sanjay" <sanjay.patil@sap.com> wrote on 13/03/2008 04:05:29:
>
> >
> > Hi Dave,
> >
> > One question from my side while Mike is still sleeping ...
> >
> > <Sanjay> As I said in my email below, the use case of 'fully
> configured
> >  implementation' does not require specifying binding/target on
> > References
> >  in the ComponentType. What you need is an ability for implementations
> > to
> >  include information that would otherwise be part of deployable
> > composites,
> >  and this issue belongs to the C&I specifications, IMO. </Sanjay>)
> > <dab> If you had such an implementation and then generated a
> > componentType
> > from it, would it not look exactly as this proposal describes? </dab>
> >
> > Question: Why in the world do you need to generate a componentType for
> > this use case of 'directly deploying a fully configured
> implementation'?
> > I thought you wanted to directly deploy a fully configured
> > implementation because pointy brackets may hurt and bleed, right? So
> > just go ahead and deploy the fully configured implementation. Why
> bother
> > about generating a componentType (which would have pointy brackets)?
> >
> > -- Sanjay
> >
> > > -----Original Message-----
> > > From: David Booz [mailto:booz@us.ibm.com]
> > > Sent: Wednesday, Mar 12, 2008 20:26 PM
> > > To: sca-assembly@lists.oasis-open.org
> > > Subject: RE: [sca-assembly] ISSUE 5: Component type allows to
> > > specify wire targets on references: PROPOSAL
> > >
> > > some quick answers while Mike is sleeping.....<dab> like this </dab>
> > >
> > > Dave Booz
> > > STSM, SCA and WebSphere Architecture
> > > Co-Chair OASIS SCA-Policy TC
> > > "Distributed objects first, then world hunger"
> > > Poughkeepsie, NY (845)-435-6093  or  8-295-6093
> > > e-mail:booz@us.ibm.com
> > > http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
> > >
> > >
> > >                                                              
> > >              
> > >              "Patil, Sanjay"                                  
> > >              
> > >              <sanjay.patil@sap                                
> > >              
> > >              .com>                                            
> > >           To
> > >                                        "Mike Edwards"        
> > >              
> > >              03/12/2008 05:43          
> > > <mike_edwards@uk.ibm.com>, "OASIS  
> > >              PM                        Assembly"              
> > >              
> > >                                        
> > > <sca-assembly@lists.oasis-open.org>
> > >                                                              
> > >           cc
> > >                                                              
> > >              
> > >                                                              
> > >      Subject
> > >                                        RE: [sca-assembly]
> > > ISSUE 5:        
> > >                                        Component type allows
> > > to specify    
> > >                                        wire targets on
> > > references:        
> > >                                        PROPOSAL              
> > >              
> > >                                                              
> > >              
> > >                                                              
> > >              
> > >                                                              
> > >              
> > >                                                              
> > >              
> > >                                                              
> > >              
> > >                                                              
> > >              
> > >
> > >
> > >
> > >
> > > comments/questions inline ...
> > >
> > >  From: Mike Edwards [mailto:mike_edwards@uk.ibm.com]
> > >  Sent: Wednesday, Mar 12, 2008 4:42 AM
> > >  To: OASIS Assembly
> > >  Subject: RE: [sca-assembly] ISSUE 5: Component type allows
> > > to specify wire
> > >  targets on references: PROPOSAL
> > >
> > >
> > >  Folks,
> > >
> > >  I'm finding it very hard to understand the logic behind the
> proposals
> > >  below.  They seem to complicate the SCA model for no reason.
> > >
> > >  The proposal that I favour I think is a very simple one,
> > > that fits in well
> > >  with the current structure of SCA and requires no new or special
> > >  constructs.  Basically, the model I see is one where an
> > > implementation has
> > >  a componentType.   The componentType represents
> > >  the configurable aspects of the implementation - services,
> > > references,
> > >  properties and the implementation itself (in the sense that
> > >  intents and policies can be configured on the implementation).
> > >  <Sanjay>
> > >  I think there is a distinction to be drawn between the
> > > configuration of
> > >  Services/References and that of Properties. The declaration of
> > >  Services/References by an implementation is in terms of business
> > >  interfaces  (and intents, if necessary) and a typical
> implementation
> > >  developer would rather keep the code independent of the
> > > binding/target
> > >  used by the Services/References (isn't that  one of the main value
> > >  propositions of SCA!). In other words, all the configurable
> > > aspects of
> > >  Services/References are not within the purview of the
> implementation
> > >  developer. OTOH, an implementation developer must understand
> > > the entire
> > >  structure of Properties, the range of possible values that may be
> > >  specified by the users of that implementation, etc.
> > >
> > >  With the above distinction in mind, it would seem natural for
> > >  implementations to provide defaults for Properties, but
> > > providing defaults
> > >  for bindings/targets for Services/References in the
> > > implementations would
> > >  be meddling with other roles (e.g. Deployer).
> > >  </Sanjay>
> > >  <dab> In general, I agree very strongly with your
> > > distinction.  However,
> > >  the proposal is specifically and explicitly setting that
> > > aside to enable
> > >  some use cases which are not part of the general usage.  
> > > This is about
> > >  enabling early adopters who are a) technically advanced (and
> > > therefore can
> > >  also see that they are trampling on the distinction you are
> > > making) and b)
> > >  are trying to dig in and get something running quickly.
> Dogmatically
> > >  forcing them into the general case will inhibit adoption.  
> > > I'm usually the
> > >  one that cries "simplicity first" when we start straying out
> > > of the 80%
> > >  use cases.  FWIW, I think this case is worth enabling because it
> will
> > >  foster adoption of the technology. </dab>
> > >
> > >
> > >  I see it as being a very simple idea that the configurable
> > > aspects of an
> > >  implementation may have default values for any of those
> > >  aspects.
> > >  <Sanjay> I disagree with this generalization. See my
> > > previous comment.
> > >  </Sanjay>
> > >
> > >  - That value can apply to a Property by the property having
> > > some value
> > >  defined by the implementation.
> > >  - For a service, the default value may be a specific binding and a
> > >  relative URI
> > >  - For a reference, the default value may include a specific
> > > binding and/or
> > >  a specific target for the reference, (some URI)
> > >  <Sanjay> By configuring a Property of an implementation, you
> > > are effecting
> > >  certain behavior/update that is confined to that
> > > implementation. OTOH, by
> > >  configuring a Reference with target/binding value, you are
> providing
> > >  details which the implementation does not care about. </Sanjay>
> > >  <dab> Agree, but this is about the implementor being able to
> > > play all the
> > >  roles in a quick and easy manner.  This is not about a clean
> > >  implementation, </dab>
> > >
> > >  When an implementation is used within a component, then the
> > > component can
> > >  decide to configure any or all of the configurable
> > >  aspects of the implementation.  This is true whether or not there
> are
> > >  default values for those aspects.  The component can get
> > >  exactly what it wants, for properties, for references and
> > > for services
> > >  (other than any intents, of course, which cannot be overridden).
> > >
> > >  The neat thing about defaults, is that if the component
> > > writer is OK with
> > >  the defaults present in the implementation, then it cuts down
> > >  the work required to configure the component - the component
> > > can simply
> > >  use the default values.
> > >  <Sanjay> You still need to check if the component writer is
> > > OK with the
> > >  defaults. That is not such a neat thing IMO. The component
> > > writer now has
> > >  to exercise extra caution in checking defaults for aspects
> > > that he/she
> > >  would not have expected.</Sanjay>
> > >  <dab> It's the same person in this case. </dab>
> > >
> > >  I see the "completely configured implementation" as only an
> > > extreme case
> > >  of these ideas - ie an implementation where all the
> > >  configurable aspects have default values supplied, so that,
> > > in effect *no*
> > >  configuration is required from the using component
> > >  in order for the component to work.
> > >   <Sanjay> Don't you need to 'promote' the component
> > > Services/References in
> > >  order to make them visible at the SCA Domain level? <Sanjay>
> > >  <dab> No, absolutely not....this is really an argument for
> > > another day
> > >  (and another thread) and I'll not go further here. </dab>
> > >
> > >  This has the happy side effect of allowing a particular use
> > > case to work
> > >  very neatly.  This is the "zero effort deployment" scenario,
> > >  where an implementation artifact such as a Java class or a
> > > PHP script can
> > >  be given to a (suitable) runtime and that runtime can
> > >  instantiate the implementation as a domain-level component
> > > without the
> > >  need for any further effort (ie no need to separately
> > >  supply deployment metadata), since everything necessary is
> > > defined in the
> > >  implementation artifact.  The runtime would still
> > >  in SCA terms be creating a deployment time composite for that new
> > >  component, but its contents are "trivial" in the sense that
> > >  all that is required is a component element with a name, using the
> > >  supplied implementation.
> > >   <Sanjay> As I said in my email below, the use case of
> > > 'fully configured
> > >  implementation' does not require specifying binding/target
> > > on References
> > >  in the ComponentType. What you need is an ability for
> > > implementations to
> > >  include information that would otherwise be part of
> > > deployable composites,
> > >  and this issue belongs to the C&I specifications, IMO. </Sanjay>)
> > > <dab> If you had such an implementation and then generated a
> > > componentType
> > > from it, would it not look exactly as this proposal describes?
> </dab>
> > >
> > >  I note that no-one is required to build a runtime that works
> > > this way.  A
> > >  runtime can insist on the deployment of contributions
> > >  that do contain composites.  On the other hand, I'd prefer to see
> it
> > >  possible to create a runtime that does not require such
> > >  metadata.
> > >  <Sanjay> I disagree. Supporting your proposal would at the
> > > minimum require
> > >  that a compliant assembly design time tool be aware of
> > > defaults in the
> > >  implementations/ComponentType-side-files. </Sanjay>
> > >  <dab> l think we could make those elements optional
> > > compliance points.
> > >  </dab>
> > >
> > >  Doing this in no way runs against the principles of SCA -
> > > and requires no
> > >  changes to the model either.  If a using component
> > >  wants to use the same "fully configured implementation" in a
> > > new way, it
> > >  is free to do so by configuring the implementation in
> > >  whatever way it chooses.  Simply supply a composite with a
> component
> > >  containing the necessary configuration data.
> > >   <Sanjay> I would personally favor a simple model where by -
> > > a> when a
> > >  'fully configured implementation' is directly deployed,  its 'full
> > >  configuration' is utilized as intended, b> when a 'fully configured
> > >  implementation' is  used by a component (a corner case), the
> > > deployment
> > >  specific configuration coming from that implementation is
> > > ignored (as it
> > >  was really not intended for this case). </Sanjay>
> > >  <dab> ah...a ray of light. This would make a fully configued
> > > composite
> > >  (which is an implementation) different from a fully configured Java
> > >  implementation. </dab>
> > >
> > >  Yours,  Mike.
> > >
> > >  Strategist - Emerging Technologies, SCA & SDO.
> > >  Co Chair OASIS SCA Assembly TC.
> > >  IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN,
> > > Great Britain.
> > >  Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431
> > >  Email:  mike_edwards@uk.ibm.com
> > >
> > >                                                              
> > >              
> > >  "Patil, Sanjay"                                              
> > >              
> > >  <sanjay.patil@sap.com>                                      
> > >              
> > >                                                              
> > >              
> > >                                                              
> > >           To
> > >  11/03/2008 18:50                 Mike Edwards/UK/IBM@IBMGB,
> > > "OASIS        
> > >                                   Assembly"                  
> > >              
> > >                                  
> > > <sca-assembly@lists.oasis-open.org>      
> > >                                                              
> > >           cc
> > >                                                              
> > >              
> > >                                                              
> > >      Subject
> > >                                   RE: [sca-assembly] ISSUE 5:
> > > Component    
> > >                                   type allows to specify wire
> > > targets on  
> > >                                   references: PROPOSAL        
> > >              
> > >                                                              
> > >              
> > >                                                              
> > >              
> > >                                                              
> > >              
> > >                                                              
> > >              
> > >                                                              
> > >              
> > >                                                              
> > >              
> > >                                                              
> > >              
> > >
> > >
> > >
> > >
> > >
> > >
> > >  I am guessing that the rationale behind the following
> > > proposal to close
> > >  the Issue 5 with no-action is - to allow for direct deployment of
> > >  implementation artifacts without requiring creation of any
> > > SCDL files,
> > >  etc. Assuming that as the target use case ....
> > >
> > >  I would like to note that supporting the above use case does
> > > not depend
> > >  upon inclusion of deployment specific configuration (e.g.
> > > wire targets on
> > >  references) in the ComponentType, since a simple solution to
> > > meet the use
> > >  case would be to embed the deployment specific configuration
> > > directly in
> > >  the implementation artifacts. Now an interesting question to
> > > answer would
> > >  be - Is there a language-neutral SCA construct to represent
> > > the deployment
> > >  specific configuration embedded in the implementation
> > > artifacts? Here are
> > >  some of the possible answers IMO -
> > >
> > >  a> None - there is no need to separately represent the embedded
> > >  configuration data as an SCA construct, since the goal of
> > > the use case is
> > >  to avoid creation of any SCDL files, etc.
> > >  b> Composite  - Since the SCA model expects that it is a
> > > Composite that
> > >  gets deployed to an SCA domain, it logical follows that the
> > > SCA construct
> > >  to represent the deployment specific configuration embedded in an
> > >  implementation artifact would also be a Composite (and not
> > > ComponentType)
> > >
> > >  So if at all we wanted to have an SCA construct that reflects the
> > >  deployment specific configuration in a directly deployable
> > > implementation,
> > >  we should focus on defining a mapping between a Composite and the
> > >  implementation. Mapping of deployment specific configuration
> > > embedded in
> > >  implementation artifacts to ComponentType is not necessary,
> > > and if allowed
> > >  for whatever reasons, there are potential downsides as
> > > documented in the
> > >  issue text [1].
> > >
> > >  In essence, I propose that we resolve Issue-5 by adopting
> > > the proposal
> > >  specified in the issue text, which says: Change the schema
> > > so that wire
> > >  targets cannot be specified.
> > >
> > >  Thanks,
> > >  Sanjay,
> > >
> > >
> > >  [1] http://osoa.org/jira/browse/ASSEMBLY-5
> > >
> > >  From: Mike Edwards [mailto:mike_edwards@uk.ibm.com]
> > >  Sent: Tuesday, Feb 12, 2008 4:12 AM
> > >  To: OASIS Assembly
> > >  Subject: [sca-assembly] ISSUE 5: Component type allows to
> > > specify wire
> > >  targets on references: PROPOSAL
> > >
> > >
> > >  Folks,
> > >
> > >  PROPOSAL:  Close Issue 5 with no action.
> > >
> > >  This permits the component type of a component to contain
> > > wire targets on
> > >  references.
> > >
> > >
> > >  Yours,  Mike.
> > >
> > >  Strategist - Emerging Technologies, SCA & SDO.
> > >  Co Chair OASIS SCA Assembly TC.
> > >  IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN,
> > > Great Britain.
> > >  Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431
> > >  Email:  mike_edwards@uk.ibm.com
> > >
> > >
> > >
> > >
> > >
> > >  Unless stated otherwise above:
> > >  IBM United Kingdom Limited - Registered in England and Wales
> > > with number
> > >  741598.
> > >  Registered office: PO Box 41, North Harbour, Portsmouth,
> > > Hampshire PO6 3AU
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >  Unless stated otherwise above:
> > >  IBM United Kingdom Limited - Registered in England and Wales
> > > with number
> > >  741598.
> > >  Registered office: PO Box 41, North Harbour, Portsmouth,
> > > Hampshire PO6 3AU
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > 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_workgr
> > > oups.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
>
> >
>
>
>
>
> ________________________________
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU
>
>


>
>
>
>
>






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU












Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU








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