[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [stp-dev] Re: How to create extensible EMF model (via FeatureMaps)based on multiple XSDs (with substituion groups) targeting the samenamespace
|
Hi Mike,
Thanks for the clarification. It sounds reasonable.
For non-SCA namespaced extensions for bindings, implementations,
interfaces:)?, we will for sure define extension points in STP, but no
other explicit EMF based extensions will be provided. The definition of
a new binding for example will lead to the definition of a new EMF model
that referers the SCA EMF model - it will be allowed due to the
different namespace (for the new binding). And the current Assembly spec
XSD already provides the extensibility needed (the xml subs groups).
Best regards,
Bogdan
-----Original Message-----
From: stp-dev-bounces@xxxxxxxxxxx [mailto:stp-dev-bounces@xxxxxxxxxxx]
On Behalf Of Mike Edwards
Sent: Friday, June 22, 2007 4:59 PM
To: STP Dev list
Subject: Re: [stp-dev] Re: How to create extensible EMF model (via
FeatureMaps)based on multiple XSDs (with substituion groups) targeting
the samenamespace
Folks,
Looking at this from a spec perspective, I don't see new implementation
types or binding types being added randomly to the SCA namespace.
What I'd expect to see is that new implementation types and/or new
binding types will be added to the SCA namespace at defined points,
where the spec level will be given some kind of revision (1.1, 2.0,
etc), effectively defining some newer version of the specification.
In the interim between spec levels, we would expect someone supplying a
new implementation type to define it outside the SCA namespace (foo.org
namespace, say) - it would be added to the SCA namespace once it is
adopted and standardized by the SCA spec teams.
So you may well need to consider dealing with extensions that are NOT in
the SCA namespace. However, it may be easier to deal with additions to
the SCA namespace as revision levels of the STP project, where
effectively you are moving from version x to version x+1 of SCA and
where you re-create a whole new model for the new version of SCA.
Yours, Mike.
Vatkov, Bogdan wrote:
> Hi guys,
>
> I think what we have from Ed is a No Go for the Extensible SCA v1.0
> meta-model idea. For now.
>
> Since we need all the extensions (e.g. implementation.java,
> implementation.bpel, etc.) to define elements in the same
> targetNamespace lile the assembly part does it seems that we will not
be
> able to apply this extensibility idea right now.
>
> At least I am out of ideas. If no one could propose a solution to have
> these pluggable/extensible SCA sub-spec based meta-models I would
> propose to go with the current approach - define one SCA v1.0
> meta-model that is based on all the XSDs available. And each time a
new
> XSD appears as addition to SCA the metamodel to be recreated. It is
not
> a tragedy at the end since the APIs that awere already generated will
> not change - only new classes - which are inheritors of already
defined
> classes - will be added to the SCA EMF API.
> If there are no further opinions or no other proposals I will attach
> the SCA v1.0 EMF model as one monolithic model based on the current
> collection of SCA XSDs.
>
> Any comments?
>
> Best regards,
> Bogdan
>
>
> -------- Original Message --------
> Subject: Re: How to create extensible EMF model (via FeatureMaps)
based
> on multiple XSDs (with substituion groups) targeting the same
namespace
> Date: Thu, 21 Jun 2007 22:21:10 -0400
> From: Ed Merks <merks@xxxxxxxxxx <mailto:merks@xxxxxxxxxx>>
> Organization: EclipseCorner
> Newsgroups: eclipse.modeling,eclipse.tools.emf
> References: <f5drea$d4k$1@xxxxxxxxxxxxxxxxx
> <mailto:f5drea$d4k$1@xxxxxxxxxxxxxxxxx>>
>
> Bogdan,
>
> In the future, please use the EMF newsgroup, which I've added to the
> "to" list of the reply. Unfortunately there is simply no support for
> having multiple EPackages with the same namespace. So if you have one
> giant namespace you need to have one giant EPackage. The assumption
> that, given a namespace, you can find a single EPackage that contains
> all the things defined in this namespace is a pervasive design point
> that cannot easily be circumvented.
>
>
> Bogdan Vatkov wrote:
> > Hi all,
> >
> > Please, redirect to other mailing lists/newsgroups if this is not
the
> > right newsgroup.
> >
> > I would need some advice on how to implement extensible (pluggable)
> > EMF model based on multiple XSDs.
> >
> > I would like to contribute the SCA v1.0 metamodel as chain of EMF
> > models based on corresponding XSDs. The XSDs are defined at
> > http://www.osoa.org/xmlns/sca/1.0 and the problem that I am
currently
> > facing is that one and the same targetNamespace is used across all
the
> > XSDs. In the sca-core.xsd we have several XML substitution groups
> > which end up as FeatureMaps in the EMF model. So on XSD level we
have
> > some kind of "extensibility" defined already. Now I would like to
> > "translate" this "extensibility" into the EMF models.
> > If I get the sca.xsd schema that includes all the other XSDs then
> > everything works fine - I have my FeatureMaps for the substitution
> > groups, and the generated EMF API is just fine - provides the base
> > classes and inheritor classes for those "meta-model extension
points"
> > (XML subs groups).
> > The problem is that if I do that I do not have this extensible
> > pluggable meta-models. For example in the sca-core definition we
have
> > the class Implementation and in several other XSDs we have
inheritors
> > like ImplementaionJava, ImplementationBPEL, ImplementationWeb, etc.
> >
> > So, I do now want to create one EMF model based on one XSD that
simply
> > aggregates several other XSDs. I would like to create as many EMF
> > models as XSD file we have, and the resulting EMF models/APIs to
> > inherit from each other (as defined by the XSD definitions).
> >
> > I can't use the "referenced generated models" because all the XSDs
are
> > with one and the same targetNamespace.
> >
> > I would agree to make some cosmetic changes to the XSDs coming from
> > osoa.org if it would not result into XML elements with different
> > namespaces.
> >
> > You can see some more descriptions regarding the SCA metamodels in
the
> > thread down bellow.
> >
> > Thanks in advance!
> >
> > Best regards,
> > Bogdan
> >
> >
>
------------------------------------------------------------------------
--------
>
> >
> >
> > RE: [stp-dev] SCA v1.0
> >
> > From: "Vatkov, Bogdan" <bogdan.vatkov@xxxxxxx
> <mailto:bogdan.vatkov@xxxxxxx>>
> > Date: Wed, 30 May 2007 13:18:58 +0200
> > Delivered-to: stp-dev@xxxxxxxxxxx <mailto:stp-dev@xxxxxxxxxxx>
> > Thread-index: AceiOozusjyS50ZRR6ypgWZgZyaLJwAZbpqg
> > Thread-topic: [stp-dev] SCA v1.0
> >
> >
>
------------------------------------------------------------------------
--------
>
> >
> >
> > Hi Oisin,
> >
> > The SCA metamodel is defined as follows (each metamodel corresponds
to
> > one XSD published in the spec):
> >
> > SCA Assembly metamodel [sca-core.sxd] (defines the SCA assembly
concepts
> > like: composite, composite service/reference/property, component,
> > component service/reference/property, wire)
> > As already mentioned in the STP Core project docs the SCA shema
defines
> > several XML Substitution Groups which are in turn represented by
> > FeatureMaps in EMF - it is a place in the model where you can say
for
> > example "I have a relation here to the class MyClass and any other
sub
> > class of MyClass that is defined later on". So the SCA spec by
> > definition is prepared to be extensible in non-intrusive way. You
can
> > add service interface, implementation and binding definitions.
> > Then based on the substitution groups in the assembly part there
are
> > several types of additional (non-required) metamodels defined:
> > Interface
> > WSDL Port type [sca-interface-wsdl.xsd]
> > Java Interface [sca-interface-java.xsd]
> > Implementation
> > BPEL impl type [sca-implementation-bpel.xsd]
> > SCA Composite impl type [sca-implementation-composite.xsd]
> > Java (POJO) impl type [sca-implementation-java.xsd]
> > EJB impl type [sca-implementation-ejb.xsd]
> > Web (EE) impl type [sca-implementation-web.xsd]
> > Binding
> > WS binding [sca-binding-webservice.xsd]
> > EJB binding [sca-binding-ejb.xsd]
> > JMS binding [sca-binding-jms.xsd]
> > SCA binding (translated to native binding?)
> > [sca-binding-sca.xsd]
> >
> > Those metamodels define the extension of SCA with the corresponding
> > interface description language, implementation technology, or
> > communication technology (binding).
> >
> > There is one more metamodel:
> > Policy (defines policy sets, intents, etc.) [sca-policy.xsd]
> >
> > These are also some other XSDs that will be good to be represented
by
> > EMF meta-model (models are stored in XML documents compliant with
the
> > source XSDs) eg. The contribution definition (defines contribution
type,
> > deployable type, import type, export type, etc.)
[sca-contribution.xsd]
> > - this particular one does not have relation to the assembly xsd
like
> > all the others do.
> >
> > So what I propose is to take the chance to preserve the
extensibility
> > idea the SCA spec already defined through XML substitution groups
and
> > use the FeatureMaps in EMF - AND in the same time to have a
separate
> > metamodel in EMF whenever a substitution groups is defined and
> > inheritors are defined though separate XSD document in the spec.
The
> > idea of subs groups/feature maps is already used in the current STP
Core
> > Model plugin but all the XSDs are joined in a single monolithic EMF
> > metamodel definition.
> >
> > If I now want to add new SCA impl type ... <implementation.php
.../> for
> > example I would need to recreate the EMF metamodel in the core
project
> > and if we switch to multiple EMF metamodels (corresponding to the
XSDs
> > from the spec) I would need to create one _additional_ EMF
metamodel for
> > the PHP implementation type. Or for example upgrading some of the
SCA
> > client & impl specs is also a similar usecase.
> >
> > Hope this clarifies the granularities in the current sca metamodel.
> >
> > Best regards,
> > Bogdan
> >
> >
> >
> > -----Original Message-----
> > From: stp-dev-bounces@xxxxxxxxxxx
> <mailto:stp-dev-bounces@xxxxxxxxxxx>
[mailto:stp-dev-bounces@xxxxxxxxxxx]
> > On Behalf Of Oisin Hurley
> > Sent: Wednesday, May 30, 2007 12:44 AM
> > To: STP Dev list
> > Subject: Re: [stp-dev] SCA v1.0
> >
> > Hi Bogdan,
> >
> > > I would need one short technical discussion with the community on
> > > the topic first.
> > >
> > > What I currently have is a particular set (the complete one for
> > > now) of the SCA XSDs imported as one monolithic EMF model. It is
> > > completely ok for me right now but I see problems in the future
> > > when somebody decides to define new SCA implementation or binding
> > > type. Then if we go with the current approach each extension of
the
> > > SCA spec/standard will force us to recreate the metamodel (EMF
> > > model). I would recommend to discontinue the monolitic approach
and
> > > define separate metamodels (with some references between them)
> > > based on a single XSD from the SCA spec. This would lead to a set
> > > of EMF models (15 for now).
> > > It is not a challenge to define 15 EMF models (the XSDs are
> > > defined) but I would like to ask whether the community would be
> > > comfortable with such an approach.
> > > I would like to discuss that point, make the proper changes if
> > > decided, and then to attaching the code to bugzilla entry.
> >
> > Having a monolithic approach that causes maintenance difficulties
> > as extensions are added is probably not suitable if we have the
> > goal of making it easy for extenders to use our code. So an
approach
> > that allows people to easile define an extension to a base model,
> > or set of base models, would be much better.
> >
> > 15 models seems to be a lot! I know that there is quite some
flexibility
> > in the SCA assembly - can you give us an example of the granularity
of
> > each model?
> >
> > On contribution, there's a few things to take into account. If you
are
> > proposing a patch to the existing core sub-project, then it is ok
to
> > just add the patch to bugzilla and we can all take a look at it. If
this
> > is new code, to be released to EPL by SAP (or individually as
yourself),
> > then we need to bring it into the Eclipse IP process - and we are
as
> > well
> > to get started asap!
> >
> > best regards
> > Oisin
> > _______________________________________________
> > stp-dev mailing list
> > stp-dev@xxxxxxxxxxx <mailto:stp-dev@xxxxxxxxxxx>
> > https://dev.eclipse.org/mailman/listinfo/stp-dev
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> stp-dev mailing list
> stp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/stp-dev
_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev
