Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Modeling (top-level project) » How to create extensible EMF model (via FeatureMaps) based on multiple XSDs (with substituion groups
How to create extensible EMF model (via FeatureMaps) based on multiple XSDs (with substituion groups [message #380798] Thu, 21 June 2007 08:37 Go to next message
Bogdan Vatkov is currently offline Bogdan Vatkov
Messages: 16
Registered: July 2009
Junior Member
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>
Date: Wed, 30 May 2007 13:18:58 +0200
Delivered-to: stp-dev@eclipse.org
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]
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
https://dev.eclipse.org/mailman/listinfo/stp-dev
Re: How to create extensible EMF model (via FeatureMaps) based on multiple XSDs (with substituion gr [message #380803 is a reply to message #380798] Thu, 21 June 2007 22:21 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26014
Registered: July 2009
Senior Member
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>
> Date: Wed, 30 May 2007 13:18:58 +0200
> Delivered-to: stp-dev@eclipse.org
> 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]
> 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
> https://dev.eclipse.org/mailman/listinfo/stp-dev
Re: How to create extensible EMF model (via FeatureMaps) based on multiple XSDs (with substituion gr [message #380804 is a reply to message #380803] Fri, 22 June 2007 02:05 Go to previous message
Bogdan Vatkov is currently offline Bogdan Vatkov
Messages: 16
Registered: July 2009
Junior Member
Thanks Ed!
Re: How to create extensible EMF model (via FeatureMaps) based on multiple XSDs (with substituion gr [message #594069 is a reply to message #380798] Thu, 21 June 2007 22:21 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26014
Registered: July 2009
Senior Member
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>
> Date: Wed, 30 May 2007 13:18:58 +0200
> Delivered-to: stp-dev@eclipse.org
> 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]
> 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
> https://dev.eclipse.org/mailman/listinfo/stp-dev
Re: How to create extensible EMF model (via FeatureMaps) based on multiple XSDs (with substituion gr [message #594080 is a reply to message #380803] Fri, 22 June 2007 02:05 Go to previous message
Bogdan Vatkov is currently offline Bogdan Vatkov
Messages: 16
Registered: July 2009
Junior Member
Thanks Ed!
Previous Topic:How to create extensible EMF model (via FeatureMaps) based on multiple XSDs (with substituion groups
Next Topic:XSD to Ecore - Enumeration Problem
Goto Forum:
  


Current Time: Fri Aug 29 20:34:55 EDT 2014

Powered by FUDForum. Page generated in 0.07304 seconds