• From: "Andrew Welch" <andrew.j.welch@g...>
• To: "Costello, Roger L." <costello@m...>
• Date: Wed, 9 Jul 2008 18:05:58 +0100

> 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."

Just define the types for Author in the specific schemas... so in
book-seller.xsd <Author> is defined to have both <GivenName> and
<Surname>, in book-distributor.xsd it's defined just to have
<Surname>.

I guess the drawback is, as soon as something becomes non-common it
has to be moved into each of of the specific schemas, even if only one
of them needs the change... there might be a way around that - I don't
know XML Schema well enough.


> 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.

Yeah it does look good, although I'm not keen on the
everything-is-optional approach... and I guess for anyone learning the
vocabulary they'd need to following both the schema and the schematron
to determine what's allowed for any given element (and I guess the
type information in the psvi is devalued too)


-- 
Andrew Welch
http://andrewjwelch.com
Kernow: http://kernowforsaxon.sf.net/

• References:
  • Creating a single XML vocabulary that is appropriately customized to different sub-groups within a community
    • From: "Costello, Roger L." <costello@m...>
  • Re: Creating a single XML vocabulary that is appropriately customized to different sub-groups within a community
    • From: "Andrew Welch" <andrew.j.welch@g...>
  • RE: Creating a single XML vocabulary that is appropriately customized to different sub-groups within a community
    • From: "Costello, Roger L." <costello@m...>