>> Why generate schemas dynamically?  What's the advantage of an XML
>> Schema language for this?

Consider an application that consumes schemas, say, to generate forms for
user input.  (Based on a type in a schema, it generates a form.).  Sometimes
the type can be specialized to make things easier for the human entering the
data, or for validation of the result.

For example, in a large institution like the headquarters of Microsoft, you
might have forms on the Intranet to produce documents like this for
centralized services:

<printRequest  id=:"234567">
    <printerLocation>Marketing 3rd floor east</printerLocation>
    <printerType>color laser 2400dpi</printerType>
    <paperType>glossy press release</paperType>
    <paperSize>letter</paperSize>
    <document>"\\WinAlways\c:\Results\Profits UP Again.xls"</document>
    <user>Joe Hypester</user>
</printRequest>

If the schema were static, printerLocation would likely be defined to be
some kind of string.  However, when the form is generated for the user, a
list of available, in-service printer locations could be retrieved from the
database, and, instead of having the user type in one, she could select from
the list.  The list could even be sorted to put printers known to be nearest
to the user's office near the top of the list.  In this case, generating a
schema on the fly for the PrinterLocationType as an enumeration and passing
that to the form generator would be one way to improve the presentation and
validation.  The schema cannot be static because it is the way of printers
to be out-of-service occasionally, and new ones to be added to the list
occasionally.  The template for the dynamic schema and the list of printer
locations could be merged using an XSLT in an XML-based schema language, but
this is a relatively minor benefit..

Jeff