Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Building a large XSD Schemas with annotations
Building a large XSD Schemas with annotations [message #663717] Wed, 06 April 2011 10:01 Go to next message
Renat Zubairov is currently offline Renat ZubairovFriend
Messages: 30
Registered: July 2009
Member
Hello all,

I'm working on EMF-driven model for Smooks EDI parser (http://www.smooks.org ).
We are parsing UN/EDIFACT definitions files and transforming them into model, later on model got stored as XSD so that XML describing that model can be validated.

I am using EcoreSchemaBuilder to transform my schema:

https://github.com/smooks/smooks/blob/master/edi/ect/src/mai n/java/org/milyn/ect/ecore/SchemaConverter.java#L109

I noticed when I'm creating large XSD file (with 336 classifiers with 1155 structural features) and saving it, it might take up to several minutes on modern Mac.

I did an investigation with Yourkit and it showed that most of the time the issue was in generated annotations.
In the resulting XSD I wanted to see the "ecore" annotations so that later on I would be able to reconstruct the model back from XSD and I also have my custom annotations on the model which I would like to see in XSD.
However rendering of annotations takes too much time (and memory) so by disabling annotation processing I was able to reduce time from several minutes to several seconds.

I switched off couple of methods:

https://github.com/smooks/smooks/blob/master/edi/ect/src/mai n/java/org/milyn/ect/ecore/CustomSchemaBuilder.java

However that's not the acceptable solution for me.

Is there any possible solution that would allow me to serialize ECORE to XSD quickly and reliably?

Renat
Re: Building a large XSD Schemas with annotations [message #663873 is a reply to message #663717] Wed, 06 April 2011 16:43 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30551
Registered: July 2009
Senior Member
Renat,

Comments below.

Renat Zubairov wrote:
> Hello all,
>
> I'm working on EMF-driven model for Smooks EDI parser
> (http://www.smooks.org ).
> We are parsing UN/EDIFACT definitions files and transforming them into
> model, later on model got stored as XSD so that XML describing that
> model can be validated.
>
> I am using EcoreSchemaBuilder to transform my schema:
>
> https://github.com/smooks/smooks/blob/master/edi/ect/src/mai n/java/org/milyn/ect/ecore/SchemaConverter.java#L109
>
>
> I noticed when I'm creating large XSD file (with 336 classifiers with
> 1155 structural features) and saving it, it might take up to several
> minutes on modern Mac.
>
> I did an investigation with Yourkit and it showed that most of the
> time the issue was in generated annotations. In the resulting XSD I
> wanted to see the "ecore" annotations so that later on I would be able
> to reconstruct the model back from XSD and I also have my custom
> annotations on the model which I would like to see in XSD.
> However rendering of annotations takes too much time (and memory) so
> by disabling annotation processing I was able to reduce time from
> several minutes to several seconds.
>
> I switched off couple of methods:
>
> https://github.com/smooks/smooks/blob/master/edi/ect/src/mai n/java/org/milyn/ect/ecore/CustomSchemaBuilder.java
>
>
> However that's not the acceptable solution for me.
>
> Is there any possible solution that would allow me to serialize ECORE
> to XSD quickly and reliably?
It does indeed do a serious amount of work every time the DOM is
changed. There's a listener that wants to update the associated schema
components and then a full analysis of the whole schema is triggered...

I'm not sure what to suggest. There's currently no ability to just turn
off the event listener, which probably would be a reasonable thing to
employ in this case, i.e., when DOM changes are known not to
significantly impact the schema model. Or perhaps a mode where
non-schema namespace attributes changes (other than xmlns ones) would be
ignored...
>
> Renat
>
Re: Building a large XSD Schemas with annotations [message #663944 is a reply to message #663873] Wed, 06 April 2011 21:29 Go to previous messageGo to next message
Renat Zubairov is currently offline Renat ZubairovFriend
Messages: 30
Registered: July 2009
Member
Hello Ed,

Thnx for the answer. My comments below:

Quote:

It does indeed do a serious amount of work every time the DOM is
changed. There's a listener that wants to update the associated schema
components and then a full analysis of the whole schema is triggered...



Could you please elaborate more on that, I was trying to understand what it does, any explanation would be appreciated.

Quote:

There's currently no ability to just turn
off the event listener, which probably would be a reasonable thing to
employ in this case, i.e., when DOM changes are known not to
significantly impact the schema model. Or perhaps a mode where
non-schema namespace attributes changes (other than xmlns ones) would be
ignored...



I can do that. Just need to understand what this listener does, and why it takes so much time and resources.

P.S. Nobody uses/generating large XSD schemas with EMF? Strange.
Re: Building a large XSD Schemas with annotations [message #663952 is a reply to message #663944] Wed, 06 April 2011 21:52 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 30551
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------030507090309010305060608
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Renat,

Comments below.

Renat Zubairov wrote:
> Hello Ed,
>
> Thnx for the answer. My comments below:
>
> Quote:
>> It does indeed do a serious amount of work every time the DOM is
>> changed. There's a listener that wants to update the associated
>> schema components and then a full analysis of the whole schema is
>> triggered...
>
>
> Could you please elaborate more on that, I was trying to understand
> what it does, any explanation would be appreciated.
Look in XSDSchemaImpl at this. If you set a breakpoint in the
handleEvent, you'll see it triggers a *huge *cascade of processing.

protected EventListener getEventListener()
{
if (eventListener == null)
{
class XSDSchemaEventListener implements EventListener,
Serializable
{
private static final long serialVersionUID = 1L;

public void handleEvent(Event event)
{
if (event instanceof MutationEvent)
{

>
> Quote:
>> There's currently no ability to just turn off the event listener,
>> which probably would be a reasonable thing to employ in this case,
>> i.e., when DOM changes are known not to significantly impact the
>> schema model. Or perhaps a mode where non-schema namespace attributes
>> changes (other than xmlns ones) would be ignored...
>
>
> I can do that. Just need to understand what this listener does, and
> why it takes so much time and resources.
I doubt much can be done without messing deeply with the schema model's
implementation.
>
> P.S. Nobody uses/generating large XSD schemas with EMF? Strange.
I don't imagine folks change their models so often that a few minutes
for a large schema is a big concern...

--------------030507090309010305060608
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Renat,<br>
<br>
Comments below.<br>
<br>
Renat Zubairov wrote:
<blockquote cite="mid:inilii$t7u$1@news.eclipse.org" type="cite">Hello
Ed,
<br>
<br>
Thnx for the answer. My comments below:
<br>
<br>
Quote:
<br>
<blockquote type="cite">It does indeed do a serious amount of work
every time the DOM is changed. There's a listener that wants to update
the associated schema components and then a full analysis of the whole
schema is triggered...
<br>
</blockquote>
<br>
<br>
Could you please elaborate more on that, I was trying to understand
what it does, any explanation would be appreciated.
<br>
</blockquote>
Look in XSDSchemaImpl at this.  If you set a breakpoint in the
handleEvent, you'll see it triggers a <b>huge </b>cascade of
processing.<br>
<blockquote><small>  protected EventListener getEventListener()</small><br>
<small>  {</small><br>
<small>    if (eventListener == null)</small><br>
<small>    {</small><br>
<small>      class XSDSchemaEventListener implements EventListener,
Serializable</small><br>
<small>      {</small><br>
<small>        private static final long serialVersionUID = 1L;</small><br>
<br>
<small>        public void handleEvent(Event event) </small><br>
<small>        {</small><br>
<small>          if (event instanceof MutationEvent)</small><br>
<small>          {</small><br>
</blockquote>
<blockquote cite="mid:inilii$t7u$1@news.eclipse.org" type="cite"><br>
Quote:
<br>
<blockquote type="cite">There's currently no ability to just turn off
the event listener, which probably would be a reasonable thing to
employ in this case, i.e., when DOM changes are known not to
significantly impact the schema model. Or perhaps a mode where
non-schema namespace attributes changes (other than xmlns ones) would
be ignored...
<br>
</blockquote>
<br>
<br>
I can do that. Just need to understand what this listener does, and why
it takes so much time and resources.
<br>
</blockquote>
I doubt much can be done without messing deeply with the schema model's
implementation.<br>
<blockquote cite="mid:inilii$t7u$1@news.eclipse.org" type="cite"><br>
P.S. Nobody uses/generating large XSD schemas with EMF? Strange.
<br>
</blockquote>
I don't imagine folks change their models so often that a few minutes
for a large schema is a big concern...<br>
</body>
</html>

--------------030507090309010305060608--
Previous Topic:jpa.teno-Annotation => persistence-mapping-hibernate
Next Topic:[CDO] Database backup/restore on server side
Goto Forum:
  


Current Time: Sun Oct 20 13:50:43 GMT 2019

Powered by FUDForum. Page generated in 0.02225 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top