Home » Modeling » EMF » EMF models extensions and redefinitions
| EMF models extensions and redefinitions [message #430377] |
Tue, 19 May 2009 09:25  |
|
Hi.
I am currently working on the creation of a set of models compatible
with existing XML files. These files were initially described with XSDs
using redefine mark-ups. These XSDs were then not maintained anymore and
we can't rely on them now.
The fact is I have a lot of freedom on the meta-model, but not on the
serialization. The idea of moving to EMF is to not use XSDs anymore.
There are three levels of modelisation.
The first one is based on a specification. Let's call it "basis_spec".
This level can be customized by platforms. Meaning there are some
elements that can be redefined / overwritten (the basis level has "any"
elements). Let's call this level "leaf_level".
Eventually, there are several common elements between the last level.
That's why we introduced an intermediary level, which gathers these
common elements.
So, we have:
> leaf_level -> commons -> basis_spec
Here is a small XML sample illustrating the existing XML files:
> <!-- Specification level -->
> <basis_spec:provides ...>
>
> <!-- Common elements -->
> <commons:myElement1 />
> <commons:myElement2 />
>
> <!-- Leaf elements -->
> <leaf:myElement3 />
> <leaf:myElement4 />
> <leaf:myElement5 />
> </basis_spec:provides>
With XSDs, it was achieved by redefining the type of the element
"provides" at each sub-level. My question is: how can I meta-model this
kind of files with EMF? Knowing that we want one model for the
specification, one for the commons (since it can be versioned) and one
for the leaf level.
I have first focused on a first level of extension.
In the spec model, I put the provides type abstract. I defined a
subsitution group as well. In the commons model, I defined an element
DocumentRoot which extends the one of the specification level. This new
DocumentRoot defines an element ProvidesCommons, which extends
ProvidesType and which is tied to the group.
In fact, I used what had been done in SCA Tools to extends bindings and
so on in the SCA meta-model. But the only files I can work with are like...
> <commons:provides ...>
> <commons:myElement1 />
> <commons:myElement2 />
> </commons:provides>
.... and not...
> <basis_spec:provides ...>
> <commons:myElement1 />
> <commons:myElement2 />
> </basis_spec:provides>
.... like I want.
Is there any way to bind the type ProvidesCommons to the namespace
basis_spec, even if it is defined in the package of commons? I tried
with the namespace extended meta data (value = namespace associated with
the basis_spec prefix), but it doesn't seem to work.
Any help is welcome.
Regards,
Vincent Zurczak.
--
Vincent Zurczak
EBM WebSourcing
+33 (0) 4 38 12 16 77
|
|
|
| Re: EMF models extensions and redefinitions [message #430412 is a reply to message #430377] |
Wed, 20 May 2009 10:13  |
 Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------050302070408050904070803
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Vincent,
Comments below.
Vincent Zurczak wrote:
> Hi.
>
> I am currently working on the creation of a set of models compatible
> with existing XML files. These files were initially described with
> XSDs using redefine mark-ups.
That's a formula for trouble. Redefine as been deprecated in the latest
schema specification. My politically incorrect observation would be
that redefine would have been better called ill-define.
> These XSDs were then not maintained anymore and we can't rely on them
> now.
>
> The fact is I have a lot of freedom on the meta-model, but not on the
> serialization. The idea of moving to EMF is to not use XSDs anymore.
One of the nice things about working with Ecore directly is you can
always export it to an XML schema if that's what other people want.
>
> There are three levels of modelisation.
> The first one is based on a specification. Let's call it "basis_spec".
>
> This level can be customized by platforms. Meaning there are some
> elements that can be redefined / overwritten (the basis level has
> "any" elements). Let's call this level "leaf_level".
:-( Redefinition is just so atrocious that I reached the conclusion
years ago that there is no consistent way to implement it in the XSD
model itself.
>
> Eventually, there are several common elements between the last level.
> That's why we introduced an intermediary level, which gathers these
> common elements.
>
> So, we have:
>
>> leaf_level -> commons -> basis_spec
>
>
> Here is a small XML sample illustrating the existing XML files:
>
>> <!-- Specification level -->
>> <basis_spec:provides ...>
> >
> > <!-- Common elements -->
>> <commons:myElement1 />
>> <commons:myElement2 />
>>
> > <!-- Leaf elements -->
>> <leaf:myElement3 />
>> <leaf:myElement4 />
>> <leaf:myElement5 />
>> </basis_spec:provides>
>
>
> With XSDs, it was achieved by redefining the type of the element
> "provides" at each sub-level. My question is: how can I meta-model
> this kind of files with EMF? Knowing that we want one model for the
> specification, one for the commons (since it can be versioned) and one
> for the leaf level.
I think it's better to have a base type that's extended by derived
types. Of course an instance of a derived type can always be used in any
context that allows the base type, so that type of approach is
sufficient. Another way to look at it is, how would I actually define
such a thing in Java which has no notion of redefine. The answer will
of course be some type of common base with derived interfaces to capture
the variants...
>
> I have first focused on a first level of extension.
> In the spec model, I put the provides type abstract. I defined a
> subsitution group as well.
Those are kind of a bit of a horrible thing too, but at least we have
ways of suppressing their negative impact on the API and deducing the
element names.
> In the commons model, I defined an element DocumentRoot which extends
> the one of the specification level. This new DocumentRoot defines an
> element ProvidesCommons, which extends ProvidesType and which is tied
> to the group.
>
> In fact, I used what had been done in SCA Tools to extends bindings
> and so on in the SCA meta-model. But the only files I can work with
> are like...
>
> > <commons:provides ...>
> > <commons:myElement1 />
> > <commons:myElement2 />
> > </commons:provides>
>
>
> ... and not...
>
> > <basis_spec:provides ...>
> > <commons:myElement1 />
> > <commons:myElement2 />
> > </basis_spec:provides>
>
>
> ... like I want.
> Is there any way to bind the type ProvidesCommons to the namespace
> basis_spec, even if it is defined in the package of commons? I tried
> with the namespace extended meta data (value = namespace associated
> with the basis_spec prefix), but it doesn't seem to work.
If you're trying to do something with substitution groups, it's
certainly possible to do that directly in Ecore. But to understand the
details, it's best to define it with a schema and then generate Ecore
from that to see the annotations that are produced. This blog will
likely be useful. And the pictures are pretty. :-P
<http://ed-merks.blogspot.com/2007/12/winters-icy-grip.html>
http://ed-merks.blogspot.com/2007/12/winters-icy-grip.html
>
>
> Any help is welcome.
>
>
> Regards,
>
> Vincent Zurczak.
>
>
--------------050302070408050904070803
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Vincent,<br>
<br>
Comments below.<br>
<br>
Vincent Zurczak wrote:
<blockquote cite="mid:guttu9$mem$1@build.eclipse.org" type="cite">Hi.
<br>
<br>
I am currently working on the creation of a set of models compatible
with existing XML files. These files were initially described with XSDs
using redefine mark-ups.</blockquote>
That's a formula for trouble. Redefine as been deprecated in the
latest schema specification. My politically incorrect observation
would be that redefine would have been better called ill-define.<br>
<blockquote cite="mid:guttu9$mem$1@build.eclipse.org" type="cite">
These XSDs were then not maintained anymore and we can't rely on them
now.
<br>
<br>
The fact is I have a lot of freedom on the meta-model, but not on the
serialization. The idea of moving to EMF is to not use XSDs anymore.
<br>
</blockquote>
One of the nice things about working with Ecore directly is you can
always export it to an XML schema if that's what other people want.<br>
<blockquote cite="mid:guttu9$mem$1@build.eclipse.org" type="cite"><br>
There are three levels of modelisation.
<br>
The first one is based on a specification. Let's call it "basis_spec".
<br>
<br>
This level can be customized by platforms. Meaning there are some
elements that can be redefined / overwritten (the basis level has "any"
elements). Let's call this level "leaf_level".
<br>
</blockquote>
:-( Redefinition is just so atrocious that I reached the conclusion
years ago that there is no consistent way to implement it in the XSD
model itself.<br>
<blockquote cite="mid:guttu9$mem$1@build.eclipse.org" type="cite"><br>
Eventually, there are several common elements between the last level.
That's why we introduced an intermediary level, which gathers these
common elements.
<br>
<br>
So, we have:
<br>
<br>
<blockquote type="cite">leaf_level -> commons -> basis_spec
<br>
</blockquote>
<br>
<br>
Here is a small XML sample illustrating the existing XML files:
<br>
<br>
<blockquote type="cite"><!-- Specification level -->
<br>
<basis_spec:provides ...>
<br>
</blockquote>
>
<br>
> &a mp;nbsp; <!-- Common elements -->
<br>
<blockquote type="cite"> <commons:myElement1 />
<br>
<commons:myElement2 />
<br>
<br>
</blockquote>
> &a mp;nbsp; <!-- Leaf elements -->
<br>
<blockquote type="cite"> <leaf:myElement3 />
<br>
<leaf:myElement4 />
<br>
<leaf:myElement5 />
<br>
</basis_spec:provides>
<br>
</blockquote>
<br>
<br>
With XSDs, it was achieved by redefining the type of the element
"provides" at each sub-level. My question is: how can I meta-model this
kind of files with EMF? Knowing that we want one model for the
specification, one for the commons (since it can be versioned) and one
for the leaf level.
<br>
</blockquote>
I think it's better to have a base type that's extended by derived
types. Of course an instance of a derived type can always be used in
any context that allows the base type, so that type of approach is
sufficient. Another way to look at it is, how would I actually define
such a thing in Java which has no notion of redefine. The answer will
of course be some type of common base with derived interfaces to
capture the variants...<br>
<blockquote cite="mid:guttu9$mem$1@build.eclipse.org" type="cite"><br>
I have first focused on a first level of extension.
<br>
In the spec model, I put the provides type abstract. I defined a
subsitution group as well. </blockquote>
Those are kind of a bit of a horrible thing too, but at least we have
ways of suppressing their negative impact on the API and deducing the
element names.<br>
<blockquote cite="mid:guttu9$mem$1@build.eclipse.org" type="cite">In
the commons model, I defined an element DocumentRoot which extends the
one of the specification level. This new DocumentRoot defines an
element ProvidesCommons, which extends ProvidesType and which is tied
to the group.
<br>
<br>
In fact, I used what had been done in SCA Tools to extends bindings and
so on in the SCA meta-model. But the only files I can work with are
like...
<br>
<br>
> <commons:provides ...>
<br>
> &a mp;nbsp; <commons:myElement1 />
<br>
> &a mp;nbsp; <commons:myElement2 />
<br>
> </commons:provides>
<br>
<br>
<br>
.... and not...
<br>
<br>
> <basis_spec:provides ...>
<br>
> &a mp;nbsp; <commons:myElement1 />
<br>
> &a mp;nbsp; <commons:myElement2 />
<br>
> </basis_spec:provides>
<br>
<br>
<br>
.... like I want.
<br>
Is there any way to bind the type ProvidesCommons to the namespace
basis_spec, even if it is defined in the package of commons? I tried
with the namespace extended meta data (value = namespace associated
with the basis_spec prefix), but it doesn't seem to work.
<br>
</blockquote>
If you're trying to do something with substitution groups, it's
certainly possible to do that directly in Ecore. But to understand the
details, it's best to define it with a schema and then generate Ecore
from that to see the annotations that are produced. This blog will
likely be useful. And the pictures are pretty. :-P<a
href="http://ed-merks.blogspot.com/2007/12/winters-icy-grip.html"><br>
</a>
<blockquote><a
href="http://ed-merks.blogspot.com/2007/12/winters-icy-grip.html">http://ed-merks.blogspot.com/2007/12/winters-icy-grip.html</a><br>
</blockquote>
<blockquote cite="mid:guttu9$mem$1@build.eclipse.org" type="cite"><br>
<br>
Any help is welcome.
<br>
<br>
<br>
Regards,
<br>
<br>
Vincent Zurczak.
<br>
<br>
<br>
</blockquote>
</body>
</html>
--------------050302070408050904070803--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 17:36:47 GMT 2024
Powered by FUDForum. Page generated in 0.03379 seconds |
] 
Search
Help
Register
Login
Home
