Costello, Roger L. wrote:

> EXAMPLE OF BUSINESS INTERESTS INFLUENCING XML DATA DESIGN

You've gone wrong already, as far as I'm concerned. The title should be 
"EXAMPLE OF BUSINESS INTERESTS INCORRECTLY INFLUENCING XML DATA DESIGN".

> A SME specifies, "There are three methods of payment: Paypal, money
> order, or cashier's check."
> 
> 
> Then, a business person announces, "Our business has a partnership with
> Paypal. We earn money each time a customer pays using Paypal. While we
> do accept the other payment methods, we earn no money with them. So, be
> sure to design the data so that Paypal is accentuated and the others
> are de-emphasized."
> 
> To de-emphasize the two other payment methods, the above XML data
> design is modified so that they are put lower in the data hierarchy:
> 
>    <Payment>
>        <Method>Paypal</Method>
>        <Alternate>
>            <Method>money order</Method>
>            <Method>cashier's check</Method>
>        </Alternate>
>    </Payment>

So now if the business announces that they suddenly prefer cashier's 
checks over PayPal your existing data is "bad" (whatever that might mean 
to the business).

The fact that one payment method is preferred over another is a business 
issue, not an information issue. In this case I would expect the 
business rule to manifest in the interface - certainly not in the 
underlying XML structure. I feel very strongly about this - I would put 
that XML on a par with data that described font changes.


Marcus