I don’t think it’s possible for a DTD and Schema to require that only element “b” isallowed in “inner id=b” under “outer id=2”. The DTD or Schema will just statethat “a”, “b”, and “c” are allowed under any “inner” element. If my assumption is correct, then should I just redesign my XML to havespecific names like “outer1” and “outer2” as opposed to being general?

Answer:

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 classes?one 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.