Home » Archived » 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  |
 John T.E. Timm
Messages: 161
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  |
Ed Merks
Messages: 33264
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
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Dealing with a set of large XML schemas [message #76293 is a reply to message #76259] |
Tue, 11 November 2008 21:25 |
Ed Merks
Messages: 33264
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
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Dealing with a set of large XML schemas [message #76406 is a reply to message #76293] |
Thu, 13 November 2008 23:48 |
John T.E. Timm
Messages: 161
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 |
Ed Merks
Messages: 33264
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>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Dealing with a set of large XML schemas [message #76439 is a reply to message #76422] |
Tue, 18 November 2008 18:41 |
John T.E. Timm
Messages: 161
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 |
Ed Merks
Messages: 33264
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
>>>>>
>>>
>>>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Dealing with a set of large XML schemas [message #603440 is a reply to message #76208] |
Tue, 11 November 2008 19:27 |
Ed Merks
Messages: 33264
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
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Dealing with a set of large XML schemas [message #603456 is a reply to message #76259] |
Tue, 11 November 2008 21:25 |
Ed Merks
Messages: 33264
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
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Dealing with a set of large XML schemas [message #603493 is a reply to message #76293] |
Thu, 13 November 2008 23:48 |
John T.E. Timm
Messages: 161
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 |
Ed Merks
Messages: 33264
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>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Dealing with a set of large XML schemas [message #603504 is a reply to message #76422] |
Tue, 18 November 2008 18:41 |
John T.E. Timm
Messages: 161
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 |
Ed Merks
Messages: 33264
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
>>>>>
>>>
>>>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Jan 17 12:44:38 GMT 2025
Powered by FUDForum. Page generated in 0.05107 seconds |
] 
Search
Help
Register
Login
Home
