• From: "Michael Kay" <mike@s...>
• To: "'Andrew Welch'" <andrew.j.welch@g...>,"'Philippe Poulard'" <philippe.poulard@s...>
• Date: Thu, 10 Jul 2008 10:49:16 +0100

> I forgot the other way... for a 1 schema solution define 
> extra types book-seller-author, book-distributor-author etc 
> then somehow add the appropriate xsi:type attribute to the 
> <Author> element when doing the respective validation:
> 
> <Author xsi:type="book-seller-author">
> 
> <Author xsi:type="book-distributor-author">
> 
> ...the relevant type definition will then be used instead of 
> the standard definition for <Author>.

In XSD 1.1 xsi:type gets generalized by the "conditional type assignment"
mechanism, which allows you to assign a type based on a a rule expressed as
an XPath expression. I rather like the idea of allowing this rule to
reference parameters supplied by the application when invoking validation:

<xs:alternative type="book-seller-author"
   test="$scenario='seller-view'"/>
<xs:alternative type="book-distributor-author"
   test="$scenario='distributor-view'"/>

But that's not currently allowed by the spec.

Michael Kay
http://www.saxonica.com/

• Follow-Ups:
  • Re: Creating a single XML vocabulary that is appropriately customized to different sub-groups within a community
    • From: "Andrew Welch" <andrew.j.welch@g...>

• 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 appropriatelycustomized to different sub-groups within a community
    • From: Philippe Poulard <philippe.poulard@s...>
  • Re: Creating a single XML vocabulary that is appropriately customized to different sub-groups within a community
    • From: "Andrew Welch" <andrew.j.welch@g...>