Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » Generating EMF from advanced XSDs
| | | |
| Re: Generating EMF from advanced XSDs [message #522765 is a reply to message #522691] |
Tue, 23 March 2010 20:54   |
 Igor Jacy Lino Campista
Messages: 34
Registered: July 2009 |
Member |
|
|
The XSDs of this specification represent a very particular and challenging scenario.
Taking the concept.xsd as an example..
In DITA terminology Concept redefines Topic.
concept.xsd has some xs:imports that are namespaced and are suitable for referenced genmodels. BUT it has many many direct xs:includes that are just part of the same namespace.
Similar to "concept", there is also, "task", "reference".
The DITA model is meant to be specialized. That means at some other point in time its expected that other specializations will appear, so for example "article" that specializes topic.
Specializes means it refines some elements, and add some elements extending some base ones. (i.e. as "concept" does)
At the end of the day, they are all models with some constraints.
My intentions:
1)
I want to work with instances of those models programmatically, while at the same time being able to handle those "specializations" that basically does not exist when creating a set of ecores.
2) Even if I create an ecore for "task", "concept", "topic", "reference". Since its using includes in the same namespace, each package needs an ecore that has more or less lots of same classes. (because essentially they are derivates mostly of "topic")
BTW: the topic.ecore is about 5.5 MB big. reference.ecore is about 6.9MB
3) I want to create UI bindings to the elements (targeting different client technologies).
Now, I have the feeling if I'm not using EMF for what is meant in the case of simply making the XSD->Ecore. And what I should do is simply work in the XML and XSD domain.
Perhaps the only benefit could be by customizing the ecore templates so that I could generate the UI bindings (using e4 concepts).
Any comments, suggestions or ideas?
|
|
| |
| Re: Generating EMF from advanced XSDs [message #522936 is a reply to message #522765] |
Wed, 24 March 2010 15:01 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Igor,
comment below.
Igor Jacy Lino Campista wrote:
>
> The XSDs of this specification represent a very particular and
> challenging scenario.
> Taking the concept.xsd as an example..
>
> In DITA terminology Concept redefines Topic.
If you really mean xsd:redefine, unfortunately that's an abomination
which is effectively unimplementable. It's been deprecated in the the
XML Schema 1.1 specification and I've given up trying to implement it.
>
> concept.xsd has some xs:imports that are namespaced and are suitable
> for referenced genmodels. BUT it has many many direct xs:includes that
> are just part of the same namespace.
>
> Similar to "concept", there is also, "task", "reference".
> The DITA model is meant to be specialized. That means at some other
> point in time its expected that other specializations will appear, so
> for example "article" that specializes topic.
>
> Specializes means it refines some elements, and add some elements
> extending some base ones. (i.e. as "concept" does)
Extension should work fine.
>
> At the end of the day, they are all models with some constraints.
>
> My intentions:
> 1) I want to work with instances of those models programmatically,
> while at the same time being able to handle those "specializations"
> that basically does not exist when creating a set of ecores.
That sounds a bit like this:
http://ed-merks.blogspot.com/2008/01/creating-children-you-d idnt-know.html
>
> 2) Even if I create an ecore for "task", "concept", "topic",
> "reference". Since its using includes in the same namespace, each
> package needs an ecore that has more or less lots of same classes.
> (because essentially they are derivates mostly of "topic")
>
> BTW: the topic.ecore is about 5.5 MB big. reference.ecore is about
> 6.9MB
I'm never quite sure how standards organizations can create things that
exceed the capacity of the human mind.
>
> 3) I want to create UI bindings to the elements (targeting different
> client technologies).
>
> Now, I have the feeling if I'm not using EMF for what is meant in the
> case of simply making the XSD->Ecore.
It all sounds fine except redefine is just not supportable and has no
analog in Java.
> And what I should do is simply work in the XML and XSD domain.
Yes, but XML is just so much syntactic noise, so how to work with it?
>
> Perhaps the only benefit could be by customizing the ecore templates
> so that I could generate the UI bindings (using e4 concepts).
I expect next release we'd provide specialized support for e4.
> Any comments, suggestions or ideas?
I'm not sure exactly what the problem is. You should be able to
generate the models for all the schemas. For any given namespace, you'd
want to be sure to specify all the schemas that contribute to that
namespace so you end up with one EPackage per namespace.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Generating EMF from advanced XSDs [message #523015 is a reply to message #522964] |
Wed, 24 March 2010 18:45 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Igor,
comments below.
Igor Jacy Lino Campista wrote:
> Thanks Ed for all the responses. I appreciate them a lot.
>
> Yes, its the infamous XSD:redefine indeed. :?
> OASIS DITA spec is indeed very big. I assume that the reason why
> topics are being redefined within the same namespace is the trick that
> makes specialization work in XML editors.
>
> My problem is simple: make much more with less. :twisted:
> My main goal is to create an open source tooling to work with DITA and
> perhaps DocBook. :x
> I'm investigating (note that don't expect to get any answer, its just
> for the sake of completeness):
> 1)How to best work with the DITA model. (considering its derivative
> nature)
> 2)Enabling graphical specializations.
> 3)How to deal with UI bindings for a WYSIWYG-like editor
> 4)How to adapt e4 concepts into the UI mix.
> 5)Besides the WYSIWYG-like editor tab, a there will be a tab with an
> enhanced XML editor.
You might be better in this case to use WTP's structured editing framework.
>
>
> I will most likely have also a fancy tree view that binds UI
> units/elements that subsecuently bind to XML elements, or blocks of
> XML elements. XML comments have to be respected in the serialization.
> Unknown XML elements will be kept but marked as errors (They won't
> affect the over usability of the editor). 8o
>
> DITA spec has big models and as you may infer they are not of the best
> quality. I'm almost convinced that working with several/many 5MB>
> ecore files does not make sense. -> Therefore my idea to work directly
> with the XSD instances reusing the Eclipse XML editor functionality
> and will keep the solution practical.
Yes, that might well be better for such massive schemas and where you
want to push the XML in the user's face rather than hide it from them.
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Generating EMF from advanced XSDs [message #622383 is a reply to message #622378] |
Tue, 23 March 2010 20:54 |
Igor Jacy Lino Campista
Messages: 34
Registered: July 2009 |
Member |
|
|
The XSDs of this specification represent a very particular and challenging scenario.
Taking the concept.xsd as an example..
In DITA terminology Concept redefines Topic.
concept.xsd has some xs:imports that are namespaced and are suitable for referenced genmodels. BUT it has many many direct xs:includes that are just part of the same namespace.
Similar to "concept", there is also, "task", "reference".
The DITA model is meant to be specialized. That means at some other point in time its expected that other specializations will appear, so for example "article" that specializes topic.
Specializes means it refines some elements, and add some elements extending some base ones. (i.e. as "concept" does)
At the end of the day, they are all models with some constraints.
My intentions:
1)
I want to work with instances of those models programmatically, while at the same time being able to handle those "specializations" that basically does not exist when creating a set of ecores.
2) Even if I create an ecore for "task", "concept", "topic", "reference". Since its using includes in the same namespace, each package needs an ecore that has more or less lots of same classes. (because essentially they are derivates mostly of "topic")
BTW: the topic.ecore is about 5.5 MB big. reference.ecore is about 6.9MB
3) I want to create UI bindings to the elements (targeting different client technologies).
Now, I have the feeling if I'm not using EMF for what is meant in the case of simply making the XSD->Ecore. And what I should do is simply work in the XML and XSD domain.
Perhaps the only benefit could be by customizing the ecore templates so that I could generate the UI bindings (using e4 concepts).
Any comments, suggestions or ideas?
|
|
|
| Re: Generating EMF from advanced XSDs [message #622386 is a reply to message #622378] |
Wed, 24 March 2010 14:54 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Igor,
The code to create the mapping file has some nasty combinatorial
behavior that makes it unusable for large examples so don't use it.
It's only produced for browsing the mapping and is not otherwise needed.
Igor Jacy Lino Campista wrote:
>
> Ed,
>
> In the past I have used the XSD -> Ecore quite nicely. (With mappings
> enabled in every case)
>
> Focusing on the relative set of XSDs, I can generate an ecore if I
> don't enable the schema to ecore mappings.
>
> If I enable the schema to ecore mappings then it goes inside an
> infinite loop or so it seems. I tried with a Quad Core with 8Gb of
> RAM, and after 1 hours no result of finishing.
>
> (if mappings are disabled I got a fast result)
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Generating EMF from advanced XSDs [message #622387 is a reply to message #522765] |
Wed, 24 March 2010 15:01 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Igor,
comment below.
Igor Jacy Lino Campista wrote:
>
> The XSDs of this specification represent a very particular and
> challenging scenario.
> Taking the concept.xsd as an example..
>
> In DITA terminology Concept redefines Topic.
If you really mean xsd:redefine, unfortunately that's an abomination
which is effectively unimplementable. It's been deprecated in the the
XML Schema 1.1 specification and I've given up trying to implement it.
>
> concept.xsd has some xs:imports that are namespaced and are suitable
> for referenced genmodels. BUT it has many many direct xs:includes that
> are just part of the same namespace.
>
> Similar to "concept", there is also, "task", "reference".
> The DITA model is meant to be specialized. That means at some other
> point in time its expected that other specializations will appear, so
> for example "article" that specializes topic.
>
> Specializes means it refines some elements, and add some elements
> extending some base ones. (i.e. as "concept" does)
Extension should work fine.
>
> At the end of the day, they are all models with some constraints.
>
> My intentions:
> 1) I want to work with instances of those models programmatically,
> while at the same time being able to handle those "specializations"
> that basically does not exist when creating a set of ecores.
That sounds a bit like this:
http://ed-merks.blogspot.com/2008/01/creating-children-you-d idnt-know.html
>
> 2) Even if I create an ecore for "task", "concept", "topic",
> "reference". Since its using includes in the same namespace, each
> package needs an ecore that has more or less lots of same classes.
> (because essentially they are derivates mostly of "topic")
>
> BTW: the topic.ecore is about 5.5 MB big. reference.ecore is about
> 6.9MB
I'm never quite sure how standards organizations can create things that
exceed the capacity of the human mind.
>
> 3) I want to create UI bindings to the elements (targeting different
> client technologies).
>
> Now, I have the feeling if I'm not using EMF for what is meant in the
> case of simply making the XSD->Ecore.
It all sounds fine except redefine is just not supportable and has no
analog in Java.
> And what I should do is simply work in the XML and XSD domain.
Yes, but XML is just so much syntactic noise, so how to work with it?
>
> Perhaps the only benefit could be by customizing the ecore templates
> so that I could generate the UI bindings (using e4 concepts).
I expect next release we'd provide specialized support for e4.
> Any comments, suggestions or ideas?
I'm not sure exactly what the problem is. You should be able to
generate the models for all the schemas. For any given namespace, you'd
want to be sure to specify all the schemas that contribute to that
namespace so you end up with one EPackage per namespace.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Generating EMF from advanced XSDs [message #622393 is a reply to message #622390] |
Wed, 24 March 2010 18:45 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Igor,
comments below.
Igor Jacy Lino Campista wrote:
> Thanks Ed for all the responses. I appreciate them a lot.
>
> Yes, its the infamous XSD:redefine indeed. :?
> OASIS DITA spec is indeed very big. I assume that the reason why
> topics are being redefined within the same namespace is the trick that
> makes specialization work in XML editors.
>
> My problem is simple: make much more with less. :twisted:
> My main goal is to create an open source tooling to work with DITA and
> perhaps DocBook. :x
> I'm investigating (note that don't expect to get any answer, its just
> for the sake of completeness):
> 1)How to best work with the DITA model. (considering its derivative
> nature)
> 2)Enabling graphical specializations.
> 3)How to deal with UI bindings for a WYSIWYG-like editor
> 4)How to adapt e4 concepts into the UI mix.
> 5)Besides the WYSIWYG-like editor tab, a there will be a tab with an
> enhanced XML editor.
You might be better in this case to use WTP's structured editing framework.
>
>
> I will most likely have also a fancy tree view that binds UI
> units/elements that subsecuently bind to XML elements, or blocks of
> XML elements. XML comments have to be respected in the serialization.
> Unknown XML elements will be kept but marked as errors (They won't
> affect the over usability of the editor). 8o
>
> DITA spec has big models and as you may infer they are not of the best
> quality. I'm almost convinced that working with several/many 5MB>
> ecore files does not make sense. -> Therefore my idea to work directly
> with the XSD instances reusing the Eclipse XML editor functionality
> and will keep the solution practical.
Yes, that might well be better for such massive schemas and where you
want to push the XML in the user's face rather than hide it from them.
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Sat Apr 27 00:26:08 GMT 2024
Powered by FUDForum. Page generated in 0.24522 seconds |
] 
Search
Help
Register
Login
Home
