2008/7/10 Michael Kay <mike@s...>:
>> 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'"/>


That's the perfect solution then...

That's also probably a better way for handling general co-constraints:
rather than use a load of complex assertions, just define all of the
different variations, then assign the type based on the value:

<xs:alternative type="typeA" test="@type = 'typeA' "/>
<xs:alternative type="typeB" test="@type = 'typeB' "/>

....that's surely the killer new feature!


As for passing parameters to the validation, if you couldn't do that
then perhaps you could query the filename (using document-uri() or
base-uri() don't know if that's allowed)... although that might be
fragile, it's potential workaround.


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