I am generating an XML file that must conform to an XML Schema (.xsd). The values for the XML will be obtained dynamically from a database using a data access bean. I would prefer to avoid hard-coding the node names and hierarchy in the code or storing them in a db table or tables, since this is duplicating the XSD. Instead, I would like to parse the XSD to get this information. The XSD does contain one xsd:choice node, but the rest of it is fairly simple. I should only need to get out the node names, and walk the xsd hierarchy - I would not need to reference restrictions or patterns. (At the end I will validate the XML vs. the XSD but that seems to me more straightforward.) XSOM looks to me like a likely possibility for parsing the XSD. Would this be the best option, or would I be better off with DOM, SAX, JAXP or something else? If it makes any difference, we are currently running Weblogic 10, but will be moving to Tomcat in several months.
You can handle this with the Java Architecture for XML Binding API and, possibly, the Java Reflection API. Apache XMLBeans also has a Schema Object Model. Or, you might figure out how to use javax.xml.validation.Schema object.
Putting the XML element name in a column of the datbase table that contains the data for this element is not a bad idea. This is a very explicit mapping technique and is simple. You could go crazy if you want all sorts of API and crazy code that only you will understand... the simple solution is typically the best. The concept that you are maintaining duplicate copies of the schema is only in your mind. The mapping of element name to database table and column has to go somewhere. Since the data is coming from the database table not the schema, it would be better to keep it close to the table rather than the schema or application code.
Joined: Sep 09, 2005
Thanks for the suggestions. You are of course correct that the mapping has to go somewhere. Our tech lead found a good example that uses the DOM, and javax.xml.parsers.*, so I will be using that to build the XML and then write it to file by serializing it using Xerces (or possibly make it implementation independent with JAXP). I am basically opting to put most of the mapping into the code, since I have multiple data elements per DB table, and multiple tables to deal with, as well as some code mapping and custom processing needed (the DB is complicated, but the resultant XML simple). If I stored all the mapping info in the db, I would also have to define parent/child relationships there, since the XML structure does not always reflect the entity relationships in the he DB. This is because the file is an export is for an external system with a different data model.