Silly question

why a DTD?

Wait a second...first back up more...do you need to do validation? If not, you don't HAVE to define an XSD or DTD. Useful if the XMLs are all internal. (I still recommend the XSDs, but I know a number of companies that don't define their XMLs so that they can change them on the fly)

Then, if you're needing to to do validation, why not XSD?

Depending on what makes up an option/prices I might consider moving these to attributes.

Also, I'd probably go with the nested hierarchical. Cross-references are easier to generate DB-wise and all...but once you start leveraging the XML via XPath/XSLT, you'll find you want to add in new fields, whatever, and you'll get burned with the cross-references in long-term maintenance.

DTD vs. XSD I hadn't thought about. I was using the term DTD loosely to mean "how will we structure the XML?"

Whether we need to validate or not, the code that consumes the XML needs to know what to look for, so the structure still needs to be defined IMO.

Your last paragraph basically sums up my feeling on it. We're using XLST heavily, and I've had to learn a few things about it that I'd rather not know. Like for instance: variables are immutable, but you can simulate them by creating a recursive template. Yes, XSLT supports recursion.

One of the main problems with using the cross-references is you can't just define a template and a match criterion. You have to roll your own loops. Total pain in the ass. Plus you have to select all the non-nested values and pass them into the template as parameters.

Welcome to IWETHEY!