Hi Werner,
----- Original Message ----
>
> Hi Kurt,
>
> Kurt Sorge wrote:
> > Werner,
> >
> >
> >
> > ----- Original Message ----
> >> Kurt Sorge wrote:
> >>> Hello All,
> >>>
> >>> I am trying to generate my source from a schema that includes
> >>> another schema using . The problem is that the original schema is
> >>> getting generated, then the include statement is triggering the
> >>> schema to get generated again.
> >> Just to get things as they are: you have got An XML schema A that
> >> includes B which itself happens to be including A again.
> > No A is included in B and I don't have a circular dependency. A gets
> > generated first and then when B gets generated, the source generator
> > wants to generate A again since it is included by B.
> In other words, you call the source generator for all XML schema files,
> right ?
Yes, I am placing all my schema files into one filterset and using that with
the generator.
> If that's the case, let me ask you on more question. Is there a
> 'root' XML schema which is not included by any other XML schema, but
> does itself include all the others (whether directly or transitive) ?
No, my view of the hierarchy is based on my dozen or so main xml documents
calling shared validators. Take, for instance, two xml documents:
company.xml
<?xml version="1.0"?>
<company>
<company-name>ACME Welding</company-name>
<address>
<street>1234 Anywhere Rd</street>
<city>Anytown</city>
<state>IL</state>
<postal>12345</postal>
</address>
</company>
and
person.xml
<?xml version="1.0"?>
<person>
<first-name>John</first-name>
<last-name>Random</last-name>
<address>
<street>1234 Mockingbird Ln</street>
<city>Nowheresville</city>
<state>IL</state>
<postal>12345</postal>
</address>
</person>
I would like to use 3 schema files company.xsd to generate the marshal code for
company.xml; person.xsd to generate the marshal code for person.xml and
address.xsd to help with the shared concept of address in both the company.xml
and person.xml.
The problem is that with my filterset address.xsd gets generated first, then
company.xsd and finally person.xsd. I can filter out address.xsd and leave only
company.xsd and person.xsd, but I am afraid I will still get generation errors
when person.xsd tries to include the address schema.
>
>
> >>> This would not be such a big deal, but when the second pass on
> >>> the schema tries to generate the class again, the generator
> >>> pompts for overwriting the first generation of the class. If I
> >>> tried to make this part of our continuous build system, it would
> >>> fall flat on it's face. Is there a way to automate my response
> >>> and log the warning?
> >> Yes, there is, but let's first make sure that I am getting the
> >> problem right.
> >>> I noticed Wolfgang Haug was having this same problem in 2005. I
> >>> guess my question is this; is the only workaround still to move
> >>> all schema rules into one file or is there a flag that can allow
> >>> the generator to ignore includes like there is for ignoring
> >>> imports? All of my schemas will be local to the project and
> >>> probably all in one directory.
> >>>
> >>> I don't like the idea of making this all one schema, since I will
> >>> be trying to validate at least a dozen separate xml document
> >>> types. The includes were being split out in order to share node
> >>> validation between the doc types. I guess I could take these
> >>> common fragments and put them into one file with a separate
> >>> namespace, but that just seems wrong for some reason (I cannot
> >>> put my finger on why yet).
> >>>
> >>> Thanks Kurt
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe from this list, please visit:
> >>>
> >>> http://xircles.codehaus.org/manage_email
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe from this list, please visit:
> >>
> >> http://xircles.codehaus.org/manage_email
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> > http://xircles.codehaus.org/manage_email
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
