Development for a direct XML<->Java<->JDO

What are the solutions you took into account on the ids/foreing keys problem?
Isn't it possible to define id/idref through schema?
Another option I can think of is to add informations to the generated discriptors through binding file.

This zip contains a small example how to integrate ids and foreign keys into an XML schema. It uses a class called IdIntegrator which is based on the SourceGenerator class.
Just run run.bat in the test directory.

Hello Ralf,
my input schema does not have ids and foreign key relations although it declares them implicitly (through its hierarchy or references and maxOccurs="unbounded"). Of course, you could integrate them manually, but all the information is already there, so it can be done automatically.

Hmm .. just thinking out loud .. ., I always thought that's why the XML schema huys added the <appInfo> element to the schema spewc, so that one could enrich an otherwise restricted model with application specific information. Maybe this offers a possible approach ?

Other than that, one could extend the current binding file syntax as well ...

Stefan, is there anything worth attaching already now ? Bear in mind that it does not need to be polished (yet) .. ...

The example I attached was not really complete. I have a project in which I use Castor with an automatized XML<>Java<>JDO mapping (based on XML schemata).
I would like to generalize it and post it together with an example next week.
One problem I have is that I modified the org.exolab.castor.tools.MappingTool class to have the DDL generated for me. I get the exception described in issue 1362 when using newer versions of Castor. So I have to use two different Castor jars (0.9.9 and the latest).

Thanks, Stefan. Looks like we have to start looking into CASTOR-1362 .. ., But that's after 1.0.4 has been released ...

I attached an archive with generation of mappings and DDL file from an XML schema plus a sample application (unit test).
Please have a look at test.html.

Happily reading .... .

Here's a first few (random) comments:

a) Thank you so much for your input, and all the time and effort you've put into this.
b) I guess Ralf will be amazed to see that another person has gone about implementing a DDL generator, using a mapping file as the input. I'll leave it up to Ralf to share the news in detail with you, but as part of last summer's Goggle Summer of Code, Google funded a student that worked with Ralf on implementing a fully-blown DDL generator. Ralf is just about to transfer this code into the SVN repository, and we'll be making this available for the first time as part of the upcoming 1.1 release.
c) I like your idea of generating a JDO mapping from an XML schema in general, as I believe that this is technically achievable.I just had a look at the HTML docs included with your above sample project, and I think it is one valid approach. Personally, I have a gut feeling that the information needed to establish proper relations (1:1 and 1:M) between domain entities expressed in an XML schema could and should be done through <appInf> elements, but that's a minor technical detail. In my view, that makes things much more explicit, as the user needs to model the relations himself, and I have got a feeling that we want the user to be in charge.

As already mentioned, some first view random observations ....

Just to get my idea across a bit clearer, have a look at the following XMLschema instance (derived from flight.xsd as included in above test.zip):

<?xml version = '1.0' encoding = 'UTF-8'?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:complexType name="person">
<xsd:annotation>
<xsd:appinfo>
<jdo:identity generate="true">
<xsd:attribute name="id" type="xsd:int" />
</jdo:identity>
</xsd:appinfo>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="name" type="xsd:string" />
<xsd:element name="first-name" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="official">
<xsd:complexContent>
<xsd:extension base="person">
<xsd:sequence>
<xsd:element name="title" type="xsd:string" />
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>

<xsd:element name="steward">
<xsd:complexType>
<xsd:annotation>
<xsd:appinfo>
<jdo:relation one-class="flight" />
</xsd:appinfo>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="official">
<xsd:sequence />
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>

<xsd:complexType name="plane">
<xsd:sequence>
<xsd:element name="name" type="xsd:string" />
<xsd:element name="manufacturer" type="xsd:string" />
<xsd:element name="model" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>

<xsd:element name="flight">
<xsd:annotation>
<xsd:appinfo>
<jdo:identity>
<element ref="flight/number"/>
</jdo:identity>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="number" type="xsd:string" />
<xsd:element name="plane" type="plane" />
<xsd:element name="pilot" type="official" />
<xsd:element name="copilot" type="official" />
<xsd:element ref="steward" maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>

Please note the use of the various <appInfo> elements, and that I have not really thought about the wording and terms used to model concepts such as relations ....

This way, it would be easy to provide an additional XML schema that specifies all possible model elements to be included in <appInfo> elements, allowing us (and thus the user) to express arbitrary properties of these (persistable) entities.

My aim was to integrate elements into the schema which can be directly processed and turned into class members by the SourceGenerator. Introducing elements under <xsd:appinfo> does not do this, i.e. the SourceGenerator has to be modified to process these elements.
The problem with my solution is that you have to use different mappings for creating and loading/querying and that you'll get IDs in the XML that is marshalled from an object which was loaded via JDO.

I have attached a new zip (castor-xmltojdo1.zip) with the source code for extra classes (changed MappinTool class). There is a build file for the project "Castor-Ext" to build the classes.
The test case remains the same, but is adapted to Castor 1.1 (unfortunately, it does not run with versions > 1.1).