I think Chin Chee-Kai's point is well taken as well, though it could be that what is designed here is a template for building interfaces (which again leads into the supposition that what you are talking about is essentially a second order schema - a schema used to define another schema). Not that I think it changes my original assertion, which I would modify slightly as to say a given schema should be an assertion of state, not process. The desire of the business expert involved placing a constraint upon the data model, but the question is whether this constraint is one that should have an obvious implication on the state of the model itself or is in fact part of a processing model that extends beyond the state model.


On Tue, Oct 14, 2008 at 9:04 PM, Chin Chee-Kai <cheekai@s...> wrote:








On Tue, Oct 14, 2008 at 4:45 PM, Costello, Roger L. <costello@m...>
wrote:


  
  
  

EXAMPLE OF BUSINESS INTERESTS INFLUENCING XML DATA DESIGN

    

A SME specifies, "There are three methods of payment: Paypal, money

order, or cashier's check."

    

Here is an XML data design which expresses the SME's specification:

    

  <Payment>

      <Method>Paypal</Method>

      <Method>money order</Method>

      <Method>cashier's check</Method>

  </Payment>

  
  
  

This design looks strange to me, given the usual understanding of
payment processes.  If this XML fragment is an instance, then there
should only be 1 <Method> used for the payment, with
corresponding details associated with the method (eg cashier's check
might have a check number, paypal would have an email address, etc). 
If paid 3 times, then 3 <Payment>s with 1 <Method> within; 
unlikely to have 1 <Payment> with 3 <Method>s within.



But if you're saying the technical expert (I don't like the acronym
SME, which semi-officially and often refers to Small Medium
Enterprises) recommends accepting 3 *choices* of the *values* of
<Method>s, then that recommendation would be translated into an
XML Schema as possibly a choice of fixed tokens rather than having
<Method> being instantiated 3 times in a transaction document.



Perhaps another context, such as a shopping cart of 3 items, might be
more appropriate?

<ShoppingCart>

    <Item>Book: Financial Crisis Solution - Ten Year
Series</Item>

    <Item>Book: How to get rich doing programming</Item>

    <Item>Report:  Latest voting inclination poll
results</Item>

</ShoppingCart>



regards,

Chin Chee-Kai







-- 
Kurt Cagle
Managing Editor, xml.com
O'Reilly
kurt@o...