Home » Modeling » EMF » Customizing XSD model generation mode
| | |
| Re: Customizing XSD model generation mode [message #736165 is a reply to message #736161] |
Thu, 13 October 2011 17:58   |
 Lemao 
Messages: 48
Registered: December 2009 |
Member |
|
|
There could be another problem:
** XSDConcreteComponent, for instance, has fields that are not EMF features and when the mode is changed to Reflective they remain in the class.
Is this state that is computed out of the EMF features and so can remain in the XSDConcreteComponent class when using Reflective-mode? If not, can this be turned into EMF attrs?
[Updated on: Thu, 13 October 2011 17:59] Report message to a moderator |
|
|
| Re: Customizing XSD model generation mode [message #736294 is a reply to message #736110] |
Thu, 13 October 2011 19:52 |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Lemao,
Comments below.
On 13/10/2011 5:44 PM, Lemao wrote:
> I am interested in changing the generation mode from the XSD model
> from None to Reflective, but have a few questions and concerns.
>
> As a quick test, I copied the XSD.ecore and XSD.genmodel from the jar,
> changed the mode to Reflective and regenerated.
There are about 25,000 lines of hand written code that you'll not have...
> This step worked ok for the most part except that I had to copy the
> org.eclipse.xsd.ecore package from the sources otherwise I would get
> an error trying to load some classes from the jar and some from
> somewhere else (expected). I also got a compilation error in one of
> the xsd.ecore packages (not sure what the issue was here).
That's pretty vague.
>
> 1. is feasible?
No.
> Do you know of any issues I may face?
Let me count the ways. About 25,000 lines of code...
> The generation part works (havent tested it yet due to some other
> issues). I also noticed that there are some hand written code added to
> the classes, but they seem to be additions and not really changes to
> generated methods.
It's all the stuff that's written only as English in the XML Schema
specification...
>
> 2. What is the best way keep this in sync with new releases of the
> official XSD model/jars? Extracting .ecore/.genmodel and copying
> sources around on each new release may not be the best idea.
You've got to be kidding?
>
> 3. I noticed that the XSD model keep a full dom tree in memory. Is
> there a way to turn this off?
No.
> I just need the XSD model classes and the validations.
I'm not sure you have a good grasp of why I spent four months
implementing what's in the XML Schema specification...
>
> thanks,
> -- yuri
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Customizing XSD model generation mode [message #736371 is a reply to message #736294] |
Fri, 14 October 2011 00:16 |
Lemao
Messages: 48
Registered: December 2009 |
Member |
|
|
Ed,
First of all, thanks for your reply. I am not sure what do you read from my post, but I do appreciate what EMF/XSD has to offer and all the work that has been put into.
Now, my post is as vague as the XSD/EMF documentation once you go a bit deeper than the usual how to parse an .xsd file into XSD model, how to generate an EMF model from an XSD, etc and blog posts scattered over the internet. This mailing list is the only forum to explore some of these questions. If not here, where? So, please bear with me.
Comments below...
Ed Merks wrote on Thu, 13 October 2011 15:52Lemao,
Comments below.
On 13/10/2011 5:44 PM, Lemao wrote:
> I am interested in changing the generation mode from the XSD model
> from None to Reflective, but have a few questions and concerns.
>
> As a quick test, I copied the XSD.ecore and XSD.genmodel from the jar,
> changed the mode to Reflective and regenerated.
There are about 25,000 lines of hand written code that you'll not have...
I could have a 100K lines of code in there, but if that is just code and not state/behavior would that matter for what I am trying to do? Or if I manually added state to the generated classes but they are calculated state from the modeled attributes/references?
Ed Merks wrote on Thu, 13 October 2011 15:52
> This step worked ok for the most part except that I had to copy the
> org.eclipse.xsd.ecore package from the sources otherwise I would get
> an error trying to load some classes from the jar and some from
> somewhere else (expected). I also got a compilation error in one of
> the xsd.ecore packages (not sure what the issue was here).
That's pretty vague.
I worked out the issues with building XSD from the sources I had, so I will also ignore my vague comments.
Ed Merks wrote on Thu, 13 October 2011 15:52
>
> 1. is feasible?
No.
So regenerating the XSD model using Reflective-mode is not feasible. Is that because the state is indeed split between modeled and manually-added state? Or something else?
Ed Merks wrote on Thu, 13 October 2011 15:52
> Do you know of any issues I may face?
Let me count the ways. About 25,000 lines of code...
There are 25K lines of code added to the generated XSD classes. How many fields were added? Two or three dozen? Why can't these fields become modeled attributes/references if they are really XSD state? Are they transient? If so, could they be refreshed when modeled state changes?
I am looking into how feasible it would be to have a reflective-mode XSD because I am willing to put the effort to make it happen, if it makes sense. If it is indeed impossible without a huge effort so be it, but I would like to at least understand the reasoning.
Ed Merks wrote on Thu, 13 October 2011 15:52
> The generation part works (havent tested it yet due to some other
> issues). I also noticed that there are some hand written code added to
> the classes, but they seem to be additions and not really changes to
> generated methods.
It's all the stuff that's written only as English in the XML Schema
specification...
I have been around the three-part XML Schema specification for close to 8-9 years now and dont need to come to this mailing list to hear that. The spec is huge, complex and I truly appreciate what has been done in the XSD model.
Back to the real question, I think that my comments above should shed some light into what I am looking for.
Ed Merks wrote on Thu, 13 October 2011 15:52
> 2. What is the best way keep this in sync with new releases of the
> official XSD model/jars? Extracting .ecore/.genmodel and copying
> sources around on each new release may not be the best idea.
You've got to be kidding?
Ignoring...
Ed Merks wrote on Thu, 13 October 2011 15:52
> 3. I noticed that the XSD model keep a full dom tree in memory. Is
> there a way to turn this off?
No.
Thanks.
Ed Merks wrote on Thu, 13 October 2011 15:52
> I just need the XSD model classes and the validations.
I'm not sure you have a good grasp of why I spent four months
implementing what's in the XML Schema specification...
Ed, I am not sure why you are so defensive about this post. You are not even making an effort in helping move this post forward and at times bordering the condescending.
I apologize if this post is vague, but in no way I fail to see how big the spec is, how hard it is to create something that XSD has accomplished so well, how much work has gone into it.
The easy answer to my question is 'no'. That is not why I came here. Just because there are 25K lines of code added and took 4 months to implement a huge, complicated spec is not a good reason for a 'no'. I am exploring ways to improve the usage of XSD at runtime (memory footprint, scalability/clustering) and these questions are important to me.
I appreciate your attention.
|
|
|
| Re: Customizing XSD model generation mode [message #736442 is a reply to message #736371] |
Fri, 14 October 2011 02:18 |
Lemao
Messages: 48
Registered: December 2009 |
Member |
|
|
Ed,
I basically just got the XSD model generated using Reflective mode working after a few code changes. The changes were mostly:
1. Making sure the manual code added to the XSD classes uses the generated get/set methods instead of directly accessing the class fields
2. Had to change the implementation of 7 (@generated false) methods in XSDSchemaImpl. E.g.:
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated NOT
*/
public EList<XSDAttributeDeclaration> getAttributeDeclarations()
{
return (EList<XSDAttributeDeclaration>)eGet(XSDPackage.Literals.XSD_SCHEMA__ATTRIBUTE_DECLARATIONS, true);
// if (attributeDeclarations == null)
// {
// attributeDeclarations = new XSDNamedComponentImpl.XSDNamedComponentList<XSDAttributeDeclaration>(XSDAttributeDeclaration.class, this, XSDPackage.XSD_SCHEMA__ATTRIBUTE_DECLARATIONS);
// }
// return attributeDeclarations;
}
I don't fully understand the impact of this hack (haven't spent the time figuring that out), but I assume that this will cause a problem in certain scenarios (to be dealt with later). For now, I ran a few isolated tests and the XSDMainExample sample, and it worked flawlessly (I also compared the output with the one from the standard XSD release).
So now I have a Reflective XSD that has part of the state still in the generated classes and part of the state managed by EState. The goal is to have all core state out from the XSD classes and pushed out into EState, otherwise there is no point to all this.
Is it feasible? Still not sure yet and I hope you can help me figure that out. In any case, it is looking better than a couple of days ago.
Another important part of this, is maintaining any code changes and keeping in sync with XSD new releases. No, I am not kidding... If this proves feasible (I am still optimist), even with some level of effort, then another critical point here is any patches needed to make it happen. Unless there is some kind of interest from EMF/XSD project in this, any code changes (e.g.: the various eContainer vs eContainer() or this.resolvedAttributeDeclaration vs getResolvedAttributeDeclaration()) will effectively become a fork from my side and overtime it will becomes unmanageable, unless it is incorporated in some shape/form back into the XSD stream. NOTE: I fully understand that these small changes are not even close to the toughest nuts to crack.
Taking another small step, e.g. XSDConcreteComponent has the following state manually added to it:
protected boolean updatingDOM;
protected boolean isReconciling;
protected boolean forceResolve;
protected EList<XSDConcreteComponent> xsdContents;
Q1: Could these become model attributes/references (they don't look like calculated fields to me)? For the first 3, it doesn't seem to be a big deal: is that right?
Q2: Specifically re: xsdContents I noticed that it is using a custom EContentEList namely XSDContentsEList. When using Reflective is there a way to customize the creation of the reference collection so that the implementation becomes a pure eGet(...)?
thanks.
[Updated on: Fri, 14 October 2011 02:21] Report message to a moderator |
|
|
| Re: Customizing XSD model generation mode [message #736629 is a reply to message #736371] |
Fri, 14 October 2011 07:04 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Lemao,
Comments below.
On 14/10/2011 2:16 AM, Lemao wrote:
> Ed,
> First of all, thanks for your reply. I am not sure what do you read
> from my post, but I do appreciate what EMF/XSD has to offer and all
> the work that has been put into.
> Now, my post is as vague as the XSD/EMF documentation
The EMF book is not so vague.
> once you go a bit deeper than the usual how to parse an .xsd file into
> XSD model, how to generate an EMF model from an XSD, etc and blog
> posts scattered over the internet.
There are some detailed articles.
> This mailing list is the only forum to explore some of these questions.
Regenerating the XSD API from scratch seems pointless. It wasn't so
clear why you were motivated to do that.
> If not here, where? So, please bear with me.
I'm not made of time but I'll try to be more patient.
>
> Comments below...
>
> Ed Merks wrote on Thu, 13 October 2011 15:52
>> Lemao,
>>
>> Comments below.
>>
>> On 13/10/2011 5:44 PM, Lemao wrote:
>> > I am interested in changing the generation mode from the XSD model
>> > from None to Reflective, but have a few questions and concerns.
>> >
>> > As a quick test, I copied the XSD.ecore and XSD.genmodel from the
>> jar, > changed the mode to Reflective and regenerated.
>> There are about 25,000 lines of hand written code that you'll not
>> have...
>
> I could have a 100K lines of code in there, but if that is just code
> and not state/behavior would that matter for what I am trying to do?
What are you trying to do?
> Or if I manually added state to the generated classes but they are
> calculated state from the modeled attributes/references?
Again, what's the point?
>
> Ed Merks wrote on Thu, 13 October 2011 15:52
>> > This step worked ok for the most part except that I had to copy the
>> > org.eclipse.xsd.ecore package from the sources otherwise I would
>> get > an error trying to load some classes from the jar and some from
>> > somewhere else (expected). I also got a compilation error in one of
>> > the xsd.ecore packages (not sure what the issue was here).
>> That's pretty vague.
>
>
> I worked out the issues with building XSD from the sources I had, so I
> will also ignore my vague comments.
> Ed Merks wrote on Thu, 13 October 2011 15:52
>> >
>> > 1. is feasible?
>> No.
>
>
> So regenerating the XSD model using Reflective-mode is not feasible.
It's a lot of work.
> Is that because the state is indeed split between modeled and
> manually-added state?
Yes.
> Or something else?
>
> Ed Merks wrote on Thu, 13 October 2011 15:52
>> > Do you know of any issues I may face?
>> Let me count the ways. About 25,000 lines of code...
>
>
> There are 25K lines of code added to the generated XSD classes. How
> many fields were added? Two or three dozen? Why can't these fields
> become modeled attributes/references if they are really XSD state? Are
> they transient? If so, could they be refreshed when modeled state
> changes?
>
> I am looking into how feasible it would be to have a reflective-mode
> XSD because I am willing to put the effort to make it happen, if it
> makes sense. If it is indeed impossible without a huge effort so be
> it, but I would like to at least understand the reasoning.
It seems like quite a big effort.
>
> Ed Merks wrote on Thu, 13 October 2011 15:52
>> > The generation part works (havent tested it yet due to some other >
>> issues). I also noticed that there are some hand written code added
>> to > the classes, but they seem to be additions and not really
>> changes to > generated methods.
>> It's all the stuff that's written only as English in the XML Schema
>> specification...
>
>
> I have been around the three-part XML Schema specification for close
> to 8-9 years now and dont need to come to this mailing list to hear
> that. The spec is huge, complex and I truly appreciate what has been
> done in the XSD model.
>
> Back to the real question, I think that my comments above should shed
> some light into what I am looking for.
> Ed Merks wrote on Thu, 13 October 2011 15:52
>> > 2. What is the best way keep this in sync with new releases of the
>> > official XSD model/jars? Extracting .ecore/.genmodel and copying >
>> sources around on each new release may not be the best idea.
>> You've got to be kidding?
>
>
> Ignoring...
> Ed Merks wrote on Thu, 13 October 2011 15:52
>> > 3. I noticed that the XSD model keep a full dom tree in memory. Is
>> > there a way to turn this off?
>> No.
>
>
> Thanks.
>
> Ed Merks wrote on Thu, 13 October 2011 15:52
>> > I just need the XSD model classes and the validations.
>> I'm not sure you have a good grasp of why I spent four months
>> implementing what's in the XML Schema specification...
>
>
> Ed, I am not sure why you are so defensive about this post. You are
> not even making an effort in helping move this post forward and at
> times bordering the condescending.
It's true. I was annoyed. I had the impression you were trying to get
by without needing all the hand written code, or things like the DOM,
both of which are fundamental to getting everything to work well.
> I apologize if this post is vague, but in no way I fail to see how big
> the spec is, how hard it is to create something that XSD has
> accomplished so well, how much work has gone into it.
Sorry for being a bit short. Best not to answer questions so late in
the evening...
>
> The easy answer to my question is 'no'.
I'm not sure how feasible it is to switch to reflective. In theory that
should be possible, but there is state stored in fields...
> That is not why I came here. Just because there are 25K lines of code
> added and took 4 months to implement a huge, complicated spec is not a
> good reason for a 'no'.
You will need that code.
> I am exploring ways to improve the usage of XSD at runtime (memory
> footprint, scalability/clustering) and these questions are important
> to me.
Using something like CDO?
>
> I appreciate your attention.
I'll stop assuming you're doing something pointless...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 26 06:36:09 GMT 2024
Powered by FUDForum. Page generated in 0.03122 seconds |
] 
Search
Help
Register
Login
Home
