While it is true that a DTD does define the structure of an
XML document, we believe that a predefined data model class
structure would be easier to work with.  If we were to write
something that was able to discover the structure of the
documents from the DTD, it would obviously have to be
generic enough to capture any XML document, and you would
see structures like hashtables of hashtables all over the
place.  We would probably end up writing helper classes that
would make accessing the data easier; these helper classes
would most likely end up looking a lot like our data model
classes.  Furthermore, the structure of JTRS XML documents
is not entirely contained in the DTD, the SCA places many
restrictions of the values of various elements, for example:
in dozens of instances, the DTD specifies CDATA as the
element type, but a closer inspection of the SCA reveals
that this element must be a id-reference, or must match a
set of predefined values; you certainly recognized this
fact.  We would indeed have to place some customized
interpretation on top of this generic data model that
narrows it to the SCA.  Another example: we define the
concept of a component, which is familiar to JTRS designers,
but it not necessarily represented as such in the DTD. 
There are only SPD documents, some of which contain
references to SCD documents.  We want to show these as SCA
and Non-SCA components, another interpretation we have to
put on the data model.
So why not do it anyway?  One, it's not clear what that
genericity buys us when we would have to customize it to the
SCA anyway.  On top of that, we specifically support the SCA
v2.2, and even then we feel it's unlikely that the structure
of the documents will drastically change in the near future.
That being said, we are trying to incorporate flexibility
where we see it might be useful given the time constraints
on the project.  For example: you might have noticed the
AttributeSheetFactory class in our high level design, this
class returns UI elements that allow the designer to view
and edit the attributes of a given component.  The factory
gets this information from the AttributeService object;
which has at its disposal a configuration file which
contains meta-data about each available attribute (or
element in the XML document).  The meta-data describes
constraints on the attribute's value such as type, or a list
of valid value if the SCA prescribes them.  Also, a method
for displaying an editor for the attribute is given, and the
faculties needed to represent the attribute in XML.  I can't
give you the exact details or format of how we are going to
do that because we're not quite sure, but you get the basic
idea.  This provides some flexibility; if a Harris designer
wants to change the way he thinks about an attribute, allow
some specific values, or change the type of an attribute, he
can do that.  What he can't do is add new elements to the
SCA or change the basic structure of the documents without
changing code.  Now, would the generic XML document
structure help us here?  Probably not, because there would
undoubtedly be some constraints placed on the new elements
by the SCA, which means we would have to change our
interpretations, and probably change code.
Secondly; it appears that you believe that if we were to go
directly to the DTD for all our information, it would
somehow exempt us from having to understand how the SCA
works.  While this would be great, it's not clear why this
is the case.  As I mentioned before, we need to customize
the display and operation of JVMS to the SCA, and not only
that, but also to how Harris JTRS designers think about the
SCA.  It's true, we need to know how the SCA works so we can
write our data model, but we also need to know how the SCA
works so we can represent it in a way that is consistent
with the higher level ideas of components and relationships,
which isn't really shown in the DTD in any sort of detail. 
We would need to do this whether or not we had the capacity
to generate a data model given a DTD.  I've spoken to every
member of the team, and not one thought we were wasting our
time trying to understand the SCA.  That said, we are
certainly open to suggestions on what we should be talking
about.
Then, finally, there is the bottom line.  There's no two
ways about it, we're pressed for time, and we already have
the data model in code.  Creating a generic XML DTD parser
means we would have to throw away the work we've done and
add complexity to the system; and it may be the case that
it's too late to do that and we can't afford it.
Does this mean we think you're totally wrong, or that we've
discarded your ideas?  Certainly not; we appreciate and
value your input.  I would say again that it might be useful
to sit down with you and go over our design, perhaps
together we can come up with some ways to incorporate more
flexibility that we had not thought of.
Again, everyone is invited to make their thoughts known, we
would like all the input we can get!
Thanks,
-Garrett