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
- From: Graham Charters <CHARTERS@uk.ibm.com>
- To: "Peshev, Peter" <peter.peshev@sap.com>
- Date: Sun, 16 Mar 2008 09:37:05 +0000
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 14/03/2008 17:32:41:
> 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.
<gcc>I think there's a misunderstanding. I
wasn't suggesting there should be another XML file. Far from it,
I was actually suggesting there be no XML at all. A componentType only
comes into play when reusing a fully configured implementation in an Assembly
using SCDL.</gcc>
>
> 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.
<gcc>I think the earlier misunderstanding means
the componentType tag approach is not desirable for me - it uses XML. The
"best practice" comment is interesting. In general I agree
about the separation of the information. However, I also believe
a certain class of use case (the "quick-n-dirty") is made more
difficult by requiring this separation. I'd like to support this
other class of assembly, but still be able to re-use the assets in a full
SCA assembly. </gcc>
>
> 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.
<gcc>I understand it's not existing metadata.
My point was SCA had already added new metadata to just about every
implementation type it supports, in some cases defining a whole new approach
to implementation metadata (e.g. annotations in C++ and PHP comments) </gcc>
> 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
<gcc>You're right, that is for another TC. I
think the important point for assembly is regarding enabling this approach.
It is then up to each implementation type TC to decide whether or
not to exploit it (this is where I believe we are today, and we are there
by design). I would assert it makes a lot of sense in some implementation
types, and not much sense in others. I'd like the assembly model
to be agnostic given it needs to support heterogeneity. I also think
in supporting heterogeneity we need to consider diversity of development
approaches, and diversity of organizations, as well as diversity of implementation
types.</gcc>
>
> 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]