Hi Andrew, 

> Couldn't you just have three schema's each containing their own
> definition of <book>, which import a common schema where everything
> else is defined?

> The book sellers will use book-seller.xsd, the distributor will use
> book-distributor.xsd etc...  seems simple enough?

Yes, that will work for my specific example.  

I think, however, that approach does not scale.

For example, suppose that the <Author> element has child elements:

    <Author>
        <GivenName>James</GivenName>
        <Surname>Suroweicki</Surname>
    </Author>

Suppose the book seller needs both child elements, but the book
distributor only needs the surname.

Thus, the book seller needs this:

---------------------------------------------------------
book-seller.xml
---------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<Book xmlns="http://www.books.org">
    <Title>The Wisdom of Crowds</Title>
    <Author>
        <GivenName>James</GivenName>
        <Surname>Suroweicki</Surname>
    </Author>
    <Date>2005</Date>
    <ISBN>0-385-72170-6</ISBN>
    <Publisher>Anchor Books</Publisher>
</Book>

The book distributor needs this:

---------------------------------------------------------
book-distributor.xml
---------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<Book xmlns="http://www.books.org">
    <Title>The Wisdom of Crowds</Title>
    <Author>
        <Surname>Suroweicki</Surname>
    </Author>
    <Size>5" x 8"</Size>
    <Weight>15oz</Weight>
    <MailingCost>$3.90</MailingCost>
</Book>

It is not possible for book-distributor.xsd to import from a common
book schema and say, "I want the <Author> element, but omit the
<GivenName> child element."

I like the layered approach because it scales well, and maintains a
nice separation of concerns - it keeps the task of defining the XML
vocabulary separate from the task of constraining the XML vocabulary
based on a sub-group's particular business data needs.

What do you think?

/Roger