One central XML Schema for multiple XML files?

Currently, we have several configuration XML files in use, which all handle a separate portion of our configuration. One for test sequence, one for timeout, etc. These separate XML files are all defined/validated against a single XML Schema document, which holds all the definitions used in the separate XML files. Is this good practice? Or should each type of XML file have its own, sepa开发者_JAVA技巧rate XML Schema?

There are arguments both ways - it's a judgement call. If there are common parts to the different files then a common schema certainly has benefits. If there aren't, and if the domains are so separate that there aren't likely to be, then I would go for separate schemas. But there's no easy answer. When you're defining a set of 400 application-to-application message formats for an integration backbone in a large investment bank, as one of my clients was, the disadvantages of both approaches become starkly clear.

This is a perfectly fine practice. This permits you to use some of the same types in multiple document types.

Our current practice is to have a "common.xsd" for shared types and an xsd for each root element "root1.xsd" & "root2.xsd". One criticism of XSD is that it is not clear what the root element must be. The root xsd's import/include the common xsd. This eliminates any ambiguity.