DDMS 2 SQL

[Chad]

Brian,

What do you think about adding some additional code that would convert
a DDMS document to a sequence of SQL statements suitable for storage
into a database? Currently what I do is submit a DDMS document to an
Oracle View as an XMLType and the View has a trigger on it that parses
out the DDMS document and saves it to about 10 different tables,
mostly to support the 1-to-many relationships. Ideally we'd just store
it as XML but we use other software that can only work with relational
tables, not objects so this is what we are stuck with. I think it
might be beneficial to provide a set of libraries that could create a
db structure suitable for storing a DDMS document in a relational
manner and have an API set that would allow a programmer to interact
w/ your XML Objects and handle the SQL generation for insert, update,
delete.

Thoughts?
Chad

[Brian Uri!]

Hi Chad,

I actually considered this as an early feature of the library, and
think that in general, some sort of persistence mapping for DDMS would
be very useful. However, I wanted to be careful about how many steps
removed from DDMS I get with this library, and ultimately ended up
skipping it. The reasons I had at the time:

- DDMSence was designed to be a complete representation of the DDMS
specification in Java objects. Persistence of DDMS records seems to be
a one-off or a two-off from this goal.
- The SQL generator would require adapters for the various major SQL
types (mySQL, Oracle, etc).
- The table structure itself would be very dependent on the project
using it. A complete representation of DDMS as a set of relational
tables would be possible but (at least in the space I have experience
in, NCES) most projects would end up working with a specific subset of
the data. For example, the DoD Metadata Registry uses DDMS records
inside of OWL taxonomies, but immediately maps them to taxonomy-
related database fields instead of working with the entire record. The
Net-Centric Publisher merely stores the DDMS record completely and
passes it on to the NCES Enterprise Catalog. I think that the table
structure should either be defined by the project using DDMS, or
should be defined as a standard by the DDMS Team / DoD Metadata
Working Group. If they were to come on a standard implementation, I
would definitely consider using it in some way with DDMSence.
- Although the base pieces of DDMS can be easily represented in
tables, the introduction of ICISM attribute groups and the Extensible
Layer really complicates any table relationships (even though most
users don't seem to bother will these optional pieces). I would prefer
to maintain a "comprehensive" posture with this library, rather than
come up with a table structure that is more usable but incomplete.

Without defining the table structure itself though, I think the
objects in DDMSence could probably fit fairly easily into an existing
object-relational mapping framework, such as Hibernate. Something like
the Oracle XML SQL Utility (XSU) might also be useful. In the meantime
though, I don't think it will be a primary component of DDMSence.

Regards,
BU