extensibility

Modular Schemas


While many small schemas are conveniently built in a single file, larger schemas tend to be built out of parts. XML Authority provides a set of tools for including other schemas within larger schemas that can be used to combine multiple modules into a coherent whole. Sometimes this helps multiple developers work on one schema at the same time, sometimes it lets the same set of declarations be used for multiple schemas, and sometimes it accomplishes both tasks at the same time.

It isn't always clear from the beginning how (or even if) a schema should be broken down into modules. Sometimes documents are composed of neat sets of information, all of which share the same basic assumptions about data and data structures. Other times information is distributed throughout a document structure; deciding how and if it belongs in a separate schema module can be difficult. In some cases, you'll want your schema to create a foundation which other developers can then refine with their own additions. Also, reusables that work within a single schema can sometimes be shared with other schemas. A few basic guidelines may at least help you get started, though particular cases often vary.

The overall approach your schema takes toward information can have a significant effect on the way you break your schema into modules. If your schema models documents, the document structures may provide 'natural' breakdowns. Different sections and levels of complex documents may have structures that can be easily put into their own containers. If your schema models data structures, those structures may have 'natural' breaks as well - relational database tables, for instance, can each be assigned their own schema, and those schemas can be used as modules in a combined larger schema when a query joins results from those tables. The way you've used reusables can sometimes give you hints as to what parts of your schema are closely related.

Of course, the 'naturalness' of such divisions is often contestable, and different analysts may see different ways to split a schema. If there aren't clear divisions within a schema's contents, it may be necessary to examine how the modules will be used (or reused). 'Natural' divisions are convenient because they reflect different categories of information that can be separated cleanly and reused in different contexts, but sometimes it is more important to divide information based on how it will be used across multiple schemas rather than how it will fit into the information set of a particular schema.

In more complex cases, you'll have multiple groups of people to contend with, and splitting the schema along workgroup lines may sometimes be appropriate. This can be dangerous if your workgroups aren't clearly assigned particular areas, and often requires significant coordination. Despite the coordination costs, this approach can be very useful when multiple groups need to modify particular areas without generating conflicts.

There are a few very basic rules you need to remember when creating schemas that use (or will be used as) modules:

Experience is often the only guide to what works in a given situation, but the guidelines above should provide you with a place to start.

Copyright 2000 Extensibility, Inc.

Suite 250, 200 Franklin Street, Chapel Hill, North Carolina 27516