What is meant by modularity in an XML schema? [closed]

Question

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.

Closed 8 years ago.

What is meant by modularity in an XML schema? i.e. given an xsd, what could be done to make it modular?

Answer 1

I would measure modularity by the reusability of the components and the strength (or rather weakness) of their coupling. For example a schema in which the complex types are named, and referenced from the element declarations, is more modular than one in which the types appear inline within the element declarations, because the types can then be reused for other elements (perhaps after refining them by extension or restriction).

Some people might look at modularity more at the level of schema documents (and therefore xs:include), but I think that's probably less important.

Of course, breaking up a system into the largest possible number of the smallest possible components is not necessarily the right thing to do; there are other factors to consider.

Answer 2

It means breaking up the XSD (file) in two or more XSDs, linked together through, most commonly, xsd:include/xsd:import. This "breaking" would be done according do the principles that guide modularity. E.g.:

• Use subject areas found in the domain of modeling (customers, accounts, products, billing, transactions, are some examples).
• Enforcement or adoption of a model through reuse (enforce a certain type system or hierarchy)
• Separation of proprietary extensions from core standards.
• etc.

Most of the principles people would consider in encapsulating code, are applicable to good XSD modularization.