Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » XML Schema Definition (XSD) » Dealing with a set of large XML schemas
Dealing with a set of large XML schemas [message #76208] Tue, 11 November 2008 19:08 Go to next message
John T.E. Timm is currently offline John T.E. Timm
Messages: 160
Registered: July 2009
Senior Member
I have a set of large XML Schemas that are all in the same
targetNamespace. A subset of the schemas comprise core data types that are
used by all of the other schemas. In attempting to create a genmodel for
all of the schemas in one project, I ran into several issues when
generating the model code. Over 1600 classes are generated and when
compiling the Validator class in the util package, I ran into a 64k method
limit exception. So, I want to divide the schemas into two groups -- one
for core data types and the other for everything else. Ideally, I would
like two separate EMF projects, but one genmodel with two ecore models in
the same project is fine. However, because ecore models appear to be
differentiated by namespace URI, I am unable to do this. Is there a way to
keep everything in the same namespace URI, but create two separate ecore
models that depend on each other and generate code from those into two
separate packages (ultimately creating two factories and two validators,
etc.)?

Thanks,

JT
Re: Dealing with a set of large XML schemas [message #76243 is a reply to message #76208] Tue, 11 November 2008 19:27 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26054
Registered: July 2009
Senior Member
John,

Comments below.

John T.E. Timm wrote:
> I have a set of large XML Schemas that are all in the same
> targetNamespace.
That seems to be a bit of a disease with XML Schema...
> A subset of the schemas comprise core data types that are used by all
> of the other schemas. In attempting to create a genmodel for all of
> the schemas in one project, I ran into several issues when generating
> the model code. Over 1600 classes are generated and when compiling the
> Validator class in the util package, I ran into a 64k method limit
> exception.
Gross. It's an annoying limit. I wonder how a human being can manage
1600 classes. :-(
> So, I want to divide the schemas into two groups -- one for core data
> types and the other for everything else. Ideally, I would like two
> separate EMF projects, but one genmodel with two ecore models in the
> same project is fine. However, because ecore models appear to be
> differentiated by namespace URI, I am unable to do this.
Yes, there can only be one package per namespace.
> Is there a way to keep everything in the same namespace URI, but
> create two separate ecore models that depend on each other and
> generate code from those into two separate packages (ultimately
> creating two factories and two validators, etc.)?
Not really. :-(

Do you have control over these schemas or are they some type of
"industry standard" thing?
>
> Thanks,
>
> JT
>
Re: Dealing with a set of large XML schemas [message #76259 is a reply to message #76243] Tue, 11 November 2008 20:13 Go to previous messageGo to next message
John T.E. Timm is currently offline John T.E. Timm
Messages: 160
Registered: July 2009
Senior Member
The schemas are pretty much an industry standard thing. I can doctor the
schemas all I want to get the code generation to come out as desired, but
at the end of the day, I need to be able to serialize objects back into
conforming instances of the original schemas (namespace and all). I did
split the schemas up into two namespaces and generated two sets of
packagss. But now, what can I do to get the combined object models to
produce XML in the same namespace? Should I modify the PackageImpl.nsURI
value manually? Or is it not that simple?

Thanks,

JT
Re: Dealing with a set of large XML schemas [message #76293 is a reply to message #76259] Tue, 11 November 2008 21:25 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26054
Registered: July 2009
Senior Member
John,

Where there's a will, there's a way. By specializing a
BasicExtendedMetaData so that it would look in more than one package for
a given name, you probably could get around this issue. If the
serializations never use xsi:type, then the namespace of the type
definitions doesn't really matter, so you could move them to a different
namespace. For complex types with qualified element or attribute names,
you run into issues with the qualifications for those, but if they use
unqualified local elements and attributes, it would work fine.

You could manually split methods that are too big...


John T.E. Timm wrote:
> The schemas are pretty much an industry standard thing. I can doctor
> the schemas all I want to get the code generation to come out as
> desired, but at the end of the day, I need to be able to serialize
> objects back into conforming instances of the original schemas
> (namespace and all). I did split the schemas up into two namespaces
> and generated two sets of packagss. But now, what can I do to get the
> combined object models to produce XML in the same namespace? Should I
> modify the PackageImpl.nsURI value manually? Or is it not that simple?
>
> Thanks,
>
> JT
>
Re: Dealing with a set of large XML schemas [message #76406 is a reply to message #76293] Thu, 13 November 2008 23:48 Go to previous messageGo to next message
John T.E. Timm is currently offline John T.E. Timm
Messages: 160
Registered: July 2009
Senior Member
Ed,

In regards to the method you have outlined here about specializing
BasicExtendedMetaData, how do I hook that back in? Is there something that
I can put into plugin.xml? This recipe refers to something that is perhaps
related:

Recipe: Using Multiple Namespaces in the Generated EMF Editor
http://wiki.eclipse.org/EMF/Recipes

Thanks,

John

Ed Merks wrote:

> John,

> Where there's a will, there's a way. By specializing a
> BasicExtendedMetaData so that it would look in more than one package for
> a given name, you probably could get around this issue. If the
> serializations never use xsi:type, then the namespace of the type
> definitions doesn't really matter, so you could move them to a different
> namespace. For complex types with qualified element or attribute names,
> you run into issues with the qualifications for those, but if they use
> unqualified local elements and attributes, it would work fine.

> You could manually split methods that are too big...


> John T.E. Timm wrote:
>> The schemas are pretty much an industry standard thing. I can doctor
>> the schemas all I want to get the code generation to come out as
>> desired, but at the end of the day, I need to be able to serialize
>> objects back into conforming instances of the original schemas
>> (namespace and all). I did split the schemas up into two namespaces
>> and generated two sets of packagss. But now, what can I do to get the
>> combined object models to produce XML in the same namespace? Should I
>> modify the PackageImpl.nsURI value manually? Or is it not that simple?
>>
>> Thanks,
>>
>> JT
>>
Re: Dealing with a set of large XML schemas [message #76422 is a reply to message #76406] Fri, 14 November 2008 01:00 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26054
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------010600060603040305030101
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

John,

Using this XMLResource option, you can specify that your own
implementation of the API to be used:

/**
* This option allows you to tailor the XML serialization of objects.
* You should provide an ExtendedMetaData as the value of this option.
* @see org.eclipse.emf.ecore.util.BasicExtendedMetaData
*/
String OPTION_EXTENDED_META_DATA = "EXTENDED_META_DATA";

That recipe is indeed related. ExtendedMetaData does all the lookups...


John T.E. Timm wrote:
> Ed,
>
> In regards to the method you have outlined here about specializing
> BasicExtendedMetaData, how do I hook that back in? Is there something
> that I can put into plugin.xml? This recipe refers to something that
> is perhaps related:
>
> Recipe: Using Multiple Namespaces in the Generated EMF Editor
> http://wiki.eclipse.org/EMF/Recipes
>
> Thanks,
>
> John
>
> Ed Merks wrote:
>
>> John,
>
>> Where there's a will, there's a way. By specializing a
>> BasicExtendedMetaData so that it would look in more than one package
>> for a given name, you probably could get around this issue. If the
>> serializations never use xsi:type, then the namespace of the type
>> definitions doesn't really matter, so you could move them to a
>> different namespace. For complex types with qualified element or
>> attribute names, you run into issues with the qualifications for
>> those, but if they use unqualified local elements and attributes, it
>> would work fine.
>
>> You could manually split methods that are too big...
>
>
>> John T.E. Timm wrote:
>>> The schemas are pretty much an industry standard thing. I can doctor
>>> the schemas all I want to get the code generation to come out as
>>> desired, but at the end of the day, I need to be able to serialize
>>> objects back into conforming instances of the original schemas
>>> (namespace and all). I did split the schemas up into two namespaces
>>> and generated two sets of packagss. But now, what can I do to get
>>> the combined object models to produce XML in the same namespace?
>>> Should I modify the PackageImpl.nsURI value manually? Or is it not
>>> that simple?
>>>
>>> Thanks,
>>>
>>> JT
>>>
>
>

--------------010600060603040305030101
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
John,<br>
<br>
Using this XMLResource option, you can specify that your own
implementation of the API to be used:<br>
<blockquote><small>
Re: Dealing with a set of large XML schemas [message #76439 is a reply to message #76422] Tue, 18 November 2008 18:41 Go to previous messageGo to next message
John T.E. Timm is currently offline John T.E. Timm
Messages: 160
Registered: July 2009
Senior Member
Ed,

The recipe uses specialization of XMIResourceFactoryImpl. In my particular
case, should I be subclassing XMLResourceFactoryImpl or
ResourceFactoryImpl?

Thanks,

JT

Ed Merks wrote:

> John,

> Using this XMLResource option, you can specify that your own
> implementation of the API to be used:

> /**
> * This option allows you to tailor the XML serialization of objects.
> * You should provide an ExtendedMetaData as the value of this option.
> * @see org.eclipse.emf.ecore.util.BasicExtendedMetaData
> */
> String OPTION_EXTENDED_META_DATA = "EXTENDED_META_DATA";

> That recipe is indeed related. ExtendedMetaData does all the lookups...


> John T.E. Timm wrote:
>> Ed,
>>
>> In regards to the method you have outlined here about specializing
>> BasicExtendedMetaData, how do I hook that back in? Is there something
>> that I can put into plugin.xml? This recipe refers to something that
>> is perhaps related:
>>
>> Recipe: Using Multiple Namespaces in the Generated EMF Editor
>> http://wiki.eclipse.org/EMF/Recipes
>>
>> Thanks,
>>
>> John
>>
>> Ed Merks wrote:
>>
>>> John,
>>
>>> Where there's a will, there's a way. By specializing a
>>> BasicExtendedMetaData so that it would look in more than one package
>>> for a given name, you probably could get around this issue. If the
>>> serializations never use xsi:type, then the namespace of the type
>>> definitions doesn't really matter, so you could move them to a
>>> different namespace. For complex types with qualified element or
>>> attribute names, you run into issues with the qualifications for
>>> those, but if they use unqualified local elements and attributes, it
>>> would work fine.
>>
>>> You could manually split methods that are too big...
>>
>>
>>> John T.E. Timm wrote:
>>>> The schemas are pretty much an industry standard thing. I can doctor
>>>> the schemas all I want to get the code generation to come out as
>>>> desired, but at the end of the day, I need to be able to serialize
>>>> objects back into conforming instances of the original schemas
>>>> (namespace and all). I did split the schemas up into two namespaces
>>>> and generated two sets of packagss. But now, what can I do to get
>>>> the combined object models to produce XML in the same namespace?
>>>> Should I modify the PackageImpl.nsURI value manually? Or is it not
>>>> that simple?
>>>>
>>>> Thanks,
>>>>
>>>> JT
>>>>
>>
>>
Re: Dealing with a set of large XML schemas [message #76455 is a reply to message #76439] Tue, 18 November 2008 21:20 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26054
Registered: July 2009
Senior Member
John,

It's import important what kind of ResourceImpl you create than which
factory you extend. I would expect there's be a generated resource
factory impl already...


John T.E. Timm wrote:
> Ed,
>
> The recipe uses specialization of XMIResourceFactoryImpl. In my
> particular case, should I be subclassing XMLResourceFactoryImpl or
> ResourceFactoryImpl?
>
> Thanks,
>
> JT
>
> Ed Merks wrote:
>
>> John,
>
>> Using this XMLResource option, you can specify that your own
>> implementation of the API to be used:
>
>> /**
>> * This option allows you to tailor the XML serialization of
>> objects.
>> * You should provide an ExtendedMetaData as the value of this
>> option.
>> * @see org.eclipse.emf.ecore.util.BasicExtendedMetaData
>> */
>> String OPTION_EXTENDED_META_DATA = "EXTENDED_META_DATA";
>
>> That recipe is indeed related. ExtendedMetaData does all the lookups...
>
>
>> John T.E. Timm wrote:
>>> Ed,
>>>
>>> In regards to the method you have outlined here about specializing
>>> BasicExtendedMetaData, how do I hook that back in? Is there
>>> something that I can put into plugin.xml? This recipe refers to
>>> something that is perhaps related:
>>>
>>> Recipe: Using Multiple Namespaces in the Generated EMF Editor
>>> http://wiki.eclipse.org/EMF/Recipes
>>>
>>> Thanks,
>>>
>>> John
>>>
>>> Ed Merks wrote:
>>>
>>>> John,
>>>
>>>> Where there's a will, there's a way. By specializing a
>>>> BasicExtendedMetaData so that it would look in more than one
>>>> package for a given name, you probably could get around this
>>>> issue. If the serializations never use xsi:type, then the
>>>> namespace of the type definitions doesn't really matter, so you
>>>> could move them to a different namespace. For complex types with
>>>> qualified element or attribute names, you run into issues with the
>>>> qualifications for those, but if they use unqualified local
>>>> elements and attributes, it would work fine.
>>>
>>>> You could manually split methods that are too big...
>>>
>>>
>>>> John T.E. Timm wrote:
>>>>> The schemas are pretty much an industry standard thing. I can
>>>>> doctor the schemas all I want to get the code generation to come
>>>>> out as desired, but at the end of the day, I need to be able to
>>>>> serialize objects back into conforming instances of the original
>>>>> schemas (namespace and all). I did split the schemas up into two
>>>>> namespaces and generated two sets of packagss. But now, what can I
>>>>> do to get the combined object models to produce XML in the same
>>>>> namespace? Should I modify the PackageImpl.nsURI value manually?
>>>>> Or is it not that simple?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> JT
>>>>>
>>>
>>>
>
>
Re: Dealing with a set of large XML schemas [message #603440 is a reply to message #76208] Tue, 11 November 2008 19:27 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26054
Registered: July 2009
Senior Member
John,

Comments below.

John T.E. Timm wrote:
> I have a set of large XML Schemas that are all in the same
> targetNamespace.
That seems to be a bit of a disease with XML Schema...
> A subset of the schemas comprise core data types that are used by all
> of the other schemas. In attempting to create a genmodel for all of
> the schemas in one project, I ran into several issues when generating
> the model code. Over 1600 classes are generated and when compiling the
> Validator class in the util package, I ran into a 64k method limit
> exception.
Gross. It's an annoying limit. I wonder how a human being can manage
1600 classes. :-(
> So, I want to divide the schemas into two groups -- one for core data
> types and the other for everything else. Ideally, I would like two
> separate EMF projects, but one genmodel with two ecore models in the
> same project is fine. However, because ecore models appear to be
> differentiated by namespace URI, I am unable to do this.
Yes, there can only be one package per namespace.
> Is there a way to keep everything in the same namespace URI, but
> create two separate ecore models that depend on each other and
> generate code from those into two separate packages (ultimately
> creating two factories and two validators, etc.)?
Not really. :-(

Do you have control over these schemas or are they some type of
"industry standard" thing?
>
> Thanks,
>
> JT
>
Re: Dealing with a set of large XML schemas [message #603445 is a reply to message #76243] Tue, 11 November 2008 20:13 Go to previous message
John T.E. Timm is currently offline John T.E. Timm
Messages: 160
Registered: July 2009
Senior Member
The schemas are pretty much an industry standard thing. I can doctor the
schemas all I want to get the code generation to come out as desired, but
at the end of the day, I need to be able to serialize objects back into
conforming instances of the original schemas (namespace and all). I did
split the schemas up into two namespaces and generated two sets of
packagss. But now, what can I do to get the combined object models to
produce XML in the same namespace? Should I modify the PackageImpl.nsURI
value manually? Or is it not that simple?

Thanks,

JT
Re: Dealing with a set of large XML schemas [message #603456 is a reply to message #76259] Tue, 11 November 2008 21:25 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26054
Registered: July 2009
Senior Member
John,

Where there's a will, there's a way. By specializing a
BasicExtendedMetaData so that it would look in more than one package for
a given name, you probably could get around this issue. If the
serializations never use xsi:type, then the namespace of the type
definitions doesn't really matter, so you could move them to a different
namespace. For complex types with qualified element or attribute names,
you run into issues with the qualifications for those, but if they use
unqualified local elements and attributes, it would work fine.

You could manually split methods that are too big...


John T.E. Timm wrote:
> The schemas are pretty much an industry standard thing. I can doctor
> the schemas all I want to get the code generation to come out as
> desired, but at the end of the day, I need to be able to serialize
> objects back into conforming instances of the original schemas
> (namespace and all). I did split the schemas up into two namespaces
> and generated two sets of packagss. But now, what can I do to get the
> combined object models to produce XML in the same namespace? Should I
> modify the PackageImpl.nsURI value manually? Or is it not that simple?
>
> Thanks,
>
> JT
>
Re: Dealing with a set of large XML schemas [message #603493 is a reply to message #76293] Thu, 13 November 2008 23:48 Go to previous message
John T.E. Timm is currently offline John T.E. Timm
Messages: 160
Registered: July 2009
Senior Member
Ed,

In regards to the method you have outlined here about specializing
BasicExtendedMetaData, how do I hook that back in? Is there something that
I can put into plugin.xml? This recipe refers to something that is perhaps
related:

Recipe: Using Multiple Namespaces in the Generated EMF Editor
http://wiki.eclipse.org/EMF/Recipes

Thanks,

John

Ed Merks wrote:

> John,

> Where there's a will, there's a way. By specializing a
> BasicExtendedMetaData so that it would look in more than one package for
> a given name, you probably could get around this issue. If the
> serializations never use xsi:type, then the namespace of the type
> definitions doesn't really matter, so you could move them to a different
> namespace. For complex types with qualified element or attribute names,
> you run into issues with the qualifications for those, but if they use
> unqualified local elements and attributes, it would work fine.

> You could manually split methods that are too big...


> John T.E. Timm wrote:
>> The schemas are pretty much an industry standard thing. I can doctor
>> the schemas all I want to get the code generation to come out as
>> desired, but at the end of the day, I need to be able to serialize
>> objects back into conforming instances of the original schemas
>> (namespace and all). I did split the schemas up into two namespaces
>> and generated two sets of packagss. But now, what can I do to get the
>> combined object models to produce XML in the same namespace? Should I
>> modify the PackageImpl.nsURI value manually? Or is it not that simple?
>>
>> Thanks,
>>
>> JT
>>
Re: Dealing with a set of large XML schemas [message #603497 is a reply to message #76406] Fri, 14 November 2008 01:00 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26054
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------010600060603040305030101
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

John,

Using this XMLResource option, you can specify that your own
implementation of the API to be used:

/**
* This option allows you to tailor the XML serialization of objects.
* You should provide an ExtendedMetaData as the value of this option.
* @see org.eclipse.emf.ecore.util.BasicExtendedMetaData
*/
String OPTION_EXTENDED_META_DATA = "EXTENDED_META_DATA";

That recipe is indeed related. ExtendedMetaData does all the lookups...


John T.E. Timm wrote:
> Ed,
>
> In regards to the method you have outlined here about specializing
> BasicExtendedMetaData, how do I hook that back in? Is there something
> that I can put into plugin.xml? This recipe refers to something that
> is perhaps related:
>
> Recipe: Using Multiple Namespaces in the Generated EMF Editor
> http://wiki.eclipse.org/EMF/Recipes
>
> Thanks,
>
> John
>
> Ed Merks wrote:
>
>> John,
>
>> Where there's a will, there's a way. By specializing a
>> BasicExtendedMetaData so that it would look in more than one package
>> for a given name, you probably could get around this issue. If the
>> serializations never use xsi:type, then the namespace of the type
>> definitions doesn't really matter, so you could move them to a
>> different namespace. For complex types with qualified element or
>> attribute names, you run into issues with the qualifications for
>> those, but if they use unqualified local elements and attributes, it
>> would work fine.
>
>> You could manually split methods that are too big...
>
>
>> John T.E. Timm wrote:
>>> The schemas are pretty much an industry standard thing. I can doctor
>>> the schemas all I want to get the code generation to come out as
>>> desired, but at the end of the day, I need to be able to serialize
>>> objects back into conforming instances of the original schemas
>>> (namespace and all). I did split the schemas up into two namespaces
>>> and generated two sets of packagss. But now, what can I do to get
>>> the combined object models to produce XML in the same namespace?
>>> Should I modify the PackageImpl.nsURI value manually? Or is it not
>>> that simple?
>>>
>>> Thanks,
>>>
>>> JT
>>>
>
>

--------------010600060603040305030101
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
John,<br>
<br>
Using this XMLResource option, you can specify that your own
implementation of the API to be used:<br>
<blockquote><small>
Re: Dealing with a set of large XML schemas [message #603504 is a reply to message #76422] Tue, 18 November 2008 18:41 Go to previous message
John T.E. Timm is currently offline John T.E. Timm
Messages: 160
Registered: July 2009
Senior Member
Ed,

The recipe uses specialization of XMIResourceFactoryImpl. In my particular
case, should I be subclassing XMLResourceFactoryImpl or
ResourceFactoryImpl?

Thanks,

JT

Ed Merks wrote:

> John,

> Using this XMLResource option, you can specify that your own
> implementation of the API to be used:

> /**
> * This option allows you to tailor the XML serialization of objects.
> * You should provide an ExtendedMetaData as the value of this option.
> * @see org.eclipse.emf.ecore.util.BasicExtendedMetaData
> */
> String OPTION_EXTENDED_META_DATA = "EXTENDED_META_DATA";

> That recipe is indeed related. ExtendedMetaData does all the lookups...


> John T.E. Timm wrote:
>> Ed,
>>
>> In regards to the method you have outlined here about specializing
>> BasicExtendedMetaData, how do I hook that back in? Is there something
>> that I can put into plugin.xml? This recipe refers to something that
>> is perhaps related:
>>
>> Recipe: Using Multiple Namespaces in the Generated EMF Editor
>> http://wiki.eclipse.org/EMF/Recipes
>>
>> Thanks,
>>
>> John
>>
>> Ed Merks wrote:
>>
>>> John,
>>
>>> Where there's a will, there's a way. By specializing a
>>> BasicExtendedMetaData so that it would look in more than one package
>>> for a given name, you probably could get around this issue. If the
>>> serializations never use xsi:type, then the namespace of the type
>>> definitions doesn't really matter, so you could move them to a
>>> different namespace. For complex types with qualified element or
>>> attribute names, you run into issues with the qualifications for
>>> those, but if they use unqualified local elements and attributes, it
>>> would work fine.
>>
>>> You could manually split methods that are too big...
>>
>>
>>> John T.E. Timm wrote:
>>>> The schemas are pretty much an industry standard thing. I can doctor
>>>> the schemas all I want to get the code generation to come out as
>>>> desired, but at the end of the day, I need to be able to serialize
>>>> objects back into conforming instances of the original schemas
>>>> (namespace and all). I did split the schemas up into two namespaces
>>>> and generated two sets of packagss. But now, what can I do to get
>>>> the combined object models to produce XML in the same namespace?
>>>> Should I modify the PackageImpl.nsURI value manually? Or is it not
>>>> that simple?
>>>>
>>>> Thanks,
>>>>
>>>> JT
>>>>
>>
>>
Re: Dealing with a set of large XML schemas [message #603507 is a reply to message #76439] Tue, 18 November 2008 21:20 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26054
Registered: July 2009
Senior Member
John,

It's import important what kind of ResourceImpl you create than which
factory you extend. I would expect there's be a generated resource
factory impl already...


John T.E. Timm wrote:
> Ed,
>
> The recipe uses specialization of XMIResourceFactoryImpl. In my
> particular case, should I be subclassing XMLResourceFactoryImpl or
> ResourceFactoryImpl?
>
> Thanks,
>
> JT
>
> Ed Merks wrote:
>
>> John,
>
>> Using this XMLResource option, you can specify that your own
>> implementation of the API to be used:
>
>> /**
>> * This option allows you to tailor the XML serialization of
>> objects.
>> * You should provide an ExtendedMetaData as the value of this
>> option.
>> * @see org.eclipse.emf.ecore.util.BasicExtendedMetaData
>> */
>> String OPTION_EXTENDED_META_DATA = "EXTENDED_META_DATA";
>
>> That recipe is indeed related. ExtendedMetaData does all the lookups...
>
>
>> John T.E. Timm wrote:
>>> Ed,
>>>
>>> In regards to the method you have outlined here about specializing
>>> BasicExtendedMetaData, how do I hook that back in? Is there
>>> something that I can put into plugin.xml? This recipe refers to
>>> something that is perhaps related:
>>>
>>> Recipe: Using Multiple Namespaces in the Generated EMF Editor
>>> http://wiki.eclipse.org/EMF/Recipes
>>>
>>> Thanks,
>>>
>>> John
>>>
>>> Ed Merks wrote:
>>>
>>>> John,
>>>
>>>> Where there's a will, there's a way. By specializing a
>>>> BasicExtendedMetaData so that it would look in more than one
>>>> package for a given name, you probably could get around this
>>>> issue. If the serializations never use xsi:type, then the
>>>> namespace of the type definitions doesn't really matter, so you
>>>> could move them to a different namespace. For complex types with
>>>> qualified element or attribute names, you run into issues with the
>>>> qualifications for those, but if they use unqualified local
>>>> elements and attributes, it would work fine.
>>>
>>>> You could manually split methods that are too big...
>>>
>>>
>>>> John T.E. Timm wrote:
>>>>> The schemas are pretty much an industry standard thing. I can
>>>>> doctor the schemas all I want to get the code generation to come
>>>>> out as desired, but at the end of the day, I need to be able to
>>>>> serialize objects back into conforming instances of the original
>>>>> schemas (namespace and all). I did split the schemas up into two
>>>>> namespaces and generated two sets of packagss. But now, what can I
>>>>> do to get the combined object models to produce XML in the same
>>>>> namespace? Should I modify the PackageImpl.nsURI value manually?
>>>>> Or is it not that simple?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> JT
>>>>>
>>>
>>>
>
>
Previous Topic:Generated EObjectValidator class
Next Topic:xsd to xmi
Goto Forum:
  


Current Time: Sat Sep 20 14:16:57 GMT 2014

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

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