Mailing-List: contact torque-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Torque Developers List" <torque-dev@db.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
In-Reply-To: 
 <55B8568AFA5F144F886F18186BAD5B2C05FA44C6F5@durham-e2k7mb1.dukece.com>
References: 
 <55B8568AFA5F144F886F18186BAD5B2C05FA44C6F5@durham-e2k7mb1.dukece.com>
Subject: RE: XML Schema for Torque 4.0
To: "Apache Torque Developers List" <torque-dev@db.apache.org>
Message-ID: 
 <OFEDF92D85.3A1C37BE-ONC1257651.00274691-C1257651.002A3810@seitenbau.net>
From: Thomas Fischer <fischer@seitenbau.net>
Date: Fri, 16 Oct 2009 09:41:08 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII

Hi Greg,

Thanks for taking the effort to tackle this. I have been able to take a
short look now, and overall it looks good to me, though there might be some
minor issues (like I do not see to allow the text value "null" on idbroker
and such stuff)

> Is the name space correct? Should it be
> .../torque/xsd/database_4_0 to be more in line with the DTD
> naming? XSD includes a version attribute, do we need the
> _4_0 part?

>From looking at what other people do, like
http://java.sun.com/dtd/web-app_2_3.dtd
putting the version into the namespace looks convenient, because then one
can supply multiple versions to download. But maybe it makes sense to use
http://db.apache.org/torque/ prefix because then we can supply the schema
to download at the torque website in the indicated place....

> This schema has fairly "tight" attribute checking based on
> the SQL and Java standards for identifiers. Will this cause
> problems with people who have used non-standard identifiers
> that are supported by their db server. Should we have a
> "loose" and "tight" version? (Personally, I want my data
> model to always be as DB server type independent as
> possible).

Hm, not so sure here. Databases do weird stuff, e.g. I know for sure that
oracle supports german umlauts in column names (and even weirder, there are
people who are actually using these features), and in my eyes it is up to
the user to do such nonsense as he likes or decide against it. So I'd
rather not provide only a tight version. What I dislike about two separate
versions is that it makes testing more difficult, but maybe one cen provide
the tight version somehow "inofficially". If we do that, we should try to
use inheritance to define only the differences in the tight version, if
that is possible. So, in my eyes it would be the best available (though not
perfect) solution to use only a loose version. But I'm open to being
persuaded otherwise here.

> Should we be including the ddlUtils people in on this since
> they also use the DTD?

That's a good idea. I know for sure that Thomas Dudziak of ddlutils made an
attempt to create a schema version some years ago, but I'm not sure what
became of it. The ddlutils schema will be much more loose because they do
not have the java aspect in it.

> Should we think about splitting this into two name spaces
> with one being the model elements and attributes (e.g. stuff
> both ddlUtils and Torque use) and the other being the torque
> generator directives (e.g. package, basePeer, and the like)?

Provided that we can come to a common basis with the ddlUtils people, this
is a good idea IMHO.

> Obviously need to revamp the generator code to use the
> schema.

Please do not put any effort into this. I have a siggestion in the queue
for the generator. Give me one or two weeks to get it presentable.

> Not sure where this should live in the Torque 4.0 project.
> The DTD have been "buried" levels down in the resources
> directory. I think this is to make it easy to get it into
> the distro jar.
In the current setup, it should live in the generator project, as the
generator is tightly coupled to it. And there, it should live in the
src/main/resources in the appropriate package to get in the jar

> But it makes it hard to find. : )

Maybe a pointer on the web site and/or a $Id: $ part in the xsd itsself can
alleviate this.

> If people like the xsddoc output, we need to integrate the
> maven plugin into the torque project (site part?). And
> update the documentation with this.

hm, xsddoc is lgpl (http://sourceforge.net/projects/xframe/develop), but as
we do not provide it packaged, this should not be a problem IMHO.

     Thomas


---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org