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
