I am having problems designing my XML doc. I'd like to
generalize it using common structure names but it appears that the DTD/Schema
for it can't fully describe it. Here is my XML doc without the outer tags:
I don't think it's possible for a DTD and Schema to require that only element "b" is
allowed in "inner id=b" under "outer id=2". The DTD or Schema will just state
that "a", "b", and "c" are allowed under any "inner" element. If my assumption is correct, then should I just redesign my XML to have
specific names like "outer1" and "outer2" as opposed to being general?
In this situation, you really are better off creating two distinct tags, and , as you suggest. Think about the XML from an object-oriented programming standpoint. You can either create one superclass that contains all of the possible situations (and enforce it in code, an ugly proposition at best) or you can create two distinct classes that may coincidentally share the same properties, but that have different functionalities. This would be analogous to having two business classesone that had an employee's personal information, and a second that contained the same employee's pay information. Both would have a few common properties (the employee's name and possibly some form of a key, as an example), but you'd use each class in very different circumstances.
This object-oriented view toward designing your XML works effectively in a wide number of circumstances. It is part of the reason that the "canonical" XML structure emphasizes unique "property-like" tagnames, rather than more generic tag descriptors. XML is likely to be a critical part of the post-OOP world partly because it encapsulates many of the principles of OOP programming without the machine dependencies that have plagued more programmatic implementations of those same principles.