<?xml version="1.0" encoding="UTF-8"?>
<!--
Document : sql2java.cfg.xsd
Created on : June 11, 2007, 12:45 PM
Author : dge2
Description:
Purpose of XML Schema document follows.
-->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="sql2java.sf.net" targetNamespace="sql2java.sf.net">
<!-- ====================================================================== -->
<!-- == Root == -->
<!-- ====================================================================== -->
<!--
- The main configuration element. All others will be a child of this
- element.
-->
<xs:element name="sql2java" type="Sql2JavaType" />
<xs:complexType name="Sql2JavaType">
<xs:sequence>
<!--
- Import other configuration files.
-->
<xs:element ref="import" minOccurs="0" maxOccurs="unbounded" />
<!--
- The database configuration.
-->
<xs:element ref="database" minOccurs="1" maxOccurs="1" />
<!--
- The generator configuration.
-->
<xs:element ref="generation" minOccurs="1" maxOccurs="1" />
</xs:sequence>
</xs:complexType>
<!-- ====================================================================== -->
<!-- == Imports == -->
<!-- ====================================================================== -->
<!--
- Import other configuration files.
-->
<xs:element name="import">
<xs:complexType>
<xs:attribute name="resource" type="xs:string" />
</xs:complexType>
</xs:element>
<!-- ====================================================================== -->
<!-- == Database == -->
<!-- ====================================================================== -->
<!--
- The database configuration.
-
- This element will hold the database configuration. This means
- information about the driver, user and password as well as the
- connection DSN. It doesn't matter which sequence the sub-elements occur,
- they just need to be there.
-->
<xs:element name="database" >
<xs:complexType>
<xs:all>
<!--
- The driver class name.
-
- This element will hold the name of the driver to use. This will
- be the JDBC driver class.
-->
<xs:element name="driverClass" type="xs:string" />
<!--
- The connection URL.
-
- This element will define how we need to connect to the database.
- It will contain a prefix followed by the hostname and some sort
- database identification. This is however not always true. Some
- database engines will use a totally different connection url.
- if this is the case, check the database's JDBC driver
- information.
-->
<xs:element name="url" type="xs:string" />
<!--
- The username.
-->
<xs:element name="username" type="xs:string" />
<!--
- The password matching the username.
-->
<xs:element name="password" type="xs:string" />
<!--
- How to fetch the relations?
-->
<xs:element ref="relations" />
<!--
- How and when to get the nextvalue
-->
<xs:element ref="sequence" />
</xs:all>
</xs:complexType>
</xs:element>
<!--
- How to fetch the relations?
-
- We have different ways to fetch the relationships between tables. We
- can do this using Sql JDBC metadata. However there are some JDBC driver
- implementations which don't have decent metadata implementations. To
- support these databases and to let the user define relationships when
- there are none, we'll also let the user create an XML file holding the
- relationship definitions.
-
- This element will have two attributes. The attribute 'type' will define
- which type of relationship fetching we want, being 'sql' or 'xml'. The
- second attribute is only used when using XML as a fetching strategy. It
- will define the file which holds the relationship definitions.
-->
<xs:element name="relations" >
<xs:complexType>
<!--
- The relationship fetching strategy.
-
- This can be one of 'sql' or 'xml'.
-->
<xs:attribute name="source">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="sql" />
<xs:enumeration value="xml" />
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<!--
- The path to the XML relationship definition file.
-
- This attribute is only used when type equals XML. It will define
- the path to the relationship definition file.
-->
<xs:attribute name="resource" type="xs:string" />
</xs:complexType>
</xs:element>
<!--
- How do we fetch a sequence?
-
- When creating a new record in the database, we'll need to know it's
- sequence.
-
- There are two types of sequence fetching. The firstone expects us to set
- the sequence, then insert the record. This is the most simple one
- because we'll have the sequence set on our object and inside the
- database.
-
- The second way of setting the sequence is somehow different. The
- database engine will set our sequence, so we'll need to perform a select
- to get to know our sequence.
-->
<xs:element name="sequence" >
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="timing">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="before" />
<xs:enumeration value="after" />
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<!-- ====================================================================== -->
<!-- == Generator == -->
<!-- ====================================================================== -->
<!--
- The generator configuration.
-
- We need to define where to generate our result to. This means we need to
- know where to store the result. We also need to know which tables,
- schema's and columns we need to include during our generation. Both
- things can be done by defining the right data inside the 'target' and
- 'includes' elements.
-
- We also might want to include extra columns. These extra columns don't
- need to exist inside the database, but might be needed to perform
- lookups. An example of this is PostgreSQL's OID column. Some projects
- use this column to perform lookups.
-
- We also need to know which templates to use during generation. A
- collection of templates is called a feature. By defining these features
- we'll be able to define which technologies we want to use in our result.
-->
<xs:element name="generation" >
<xs:complexType>
<xs:all>
<!--
- Where do we need to store the result?
-->
<xs:element ref="target" />
<!--
- Which schema's, table's or columns do we need to include?
-->
<xs:element ref="includes" />
<!--
- Which extra columns do we need to include during generation?
-->
<xs:element ref="columns" />
<!--
- Which features will we use?
-->
<xs:element ref="features" />
</xs:all>
</xs:complexType>
</xs:element>
<!--
- Where do we need to store the result?
-
- We need to define where we want to store our generated code. We also
- need to know in which package we need to generate the code.
-->
<xs:element name="target" >
<xs:complexType>
<xs:all>
<xs:element name="package" type="xs:string" />
<xs:element name="path" type="xs:string" />
</xs:all>
</xs:complexType>
</xs:element>
<!--
- Which schema's, table's or columns do we need to include?
-
- We need to know for which types we are looking for. Should we only look
- for tables, or should we need to look at views too?
-
- After we have defined which types we need to look at, we may define a
- pattern to look for. This will make it possible to look for table
- starting with 'my_' or some other prefix.
-->
<xs:element name="includes" >
<xs:complexType>
<xs:sequence>
<xs:element ref="pattern" minOccurs="0" maxOccurs="unbounded" />
<xs:element ref="type" minOccurs="1" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
</xs:element>
<!--
- Which patterns are we looking for?
-
- After we have defined which types we need to look at, we may define a
- pattern to look for. This will make it possible to look for table
- starting with 'my_' or some other prefix.
-->
<xs:element name="pattern" >
<xs:complexType>
<xs:attribute name="type" >
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="schema" />
<xs:enumeration value="table" />
<xs:enumeration value="column" />
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="value" type="xs:string" />
</xs:complexType>
</xs:element>
<!--
- Which types are we looking at?
-
- We need to know for which types we are looking for. Should we only look
- for tables, or should we need to look at views too?
-->
<xs:element name="type">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="TABLE" />
<xs:enumeration value="VIEW" />
<xs:enumeration value="SYSTEM TABLE" />
<xs:enumeration value="GLOBAL TEMPORARY" />
<xs:enumeration value="LOCAL TEMPORARY" />
<xs:enumeration value="ALIAS" />
<xs:enumeration value="SYNONYM" />
</xs:restriction>
</xs:simpleType>
</xs:element>
<!--
- Which extra columns do we want?
-
- We also might want to include extra columns. These extra columns don't
- need to exist inside the database, but might be needed to perform
- lookups. An example of this is PostgreSQL's OID column. Some projects
- use this column to perform lookups.
-->
<xs:element name="columns" >
<xs:complexType>
<xs:sequence>
<xs:element ref="column" minOccurs="0" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="column">
<xs:complexType>
<xs:attribute name="type" >
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="schema" />
<xs:enumeration value="table" />
<xs:enumeration value="column" />
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="value" type="xs:string" />
</xs:complexType>
</xs:element>
<xs:element name="features" >
<xs:complexType>
<xs:sequence>
<xs:element name="feature" minOccurs="1" maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="resource" type="xs:string" />
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
