The question mystifies me as posed.

The data designer does not answer the question of when a business rule is
*legitimate*.   It simply is not their shot to call.   It is their job to
determine how to meet the business requirement as determined by the business
owner/manager as long as that requirement is within legal constraints.   If
the requirement impacts the performance of the system in any way, it is
their job to make this impact clear in quantitative terms.

Ugly code, unaesthetic code, or code which violates a designer's personal
beliefs about the business models are not performance impacts.

A designer can vote with their feet, of course.

len

At 6:59 PM -0400 10/15/08, Costello, Roger L. wrote:
>Hi Folks,
>
>Excellent discussion! 
>
>I revised the example, based on your comments:
>
>
>EXAMPLE OF BUSINESS INTERESTS INFLUENCING A DATA SPECIFICATION AND THE
>RESULTANT XML DATA DESIGN
>
>During the course of developing a particular data specification a SME
>states,
>
>      There are three methods of payment that our
>      company accepts: Paypal, money order, or
>      cashier's check.
>
>The SME's statement is added to the data specification.
>
>Then, a business person reads the statement and says:
>
>      Our company 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 add a sentence that Paypal is the
>      preferred payment method.
>
>As a result of this business interest, another sentence is added to the
>data specification:
>
>      There are three methods of payment that our
>      company accepts: Paypal, money order, or
>      cashier's check. However, the preferred
>      method is Paypal.
>
>
>IMPLEMENTATION
>
>Without the input from the business person, the data specification is
>translated into this implementation:
>
>    <Accepted-Payment-Methods>
>        <Method>Paypal</Method>
>        <Method>money order</Method>
>        <Method>cashier's check</Method>
>    </Accepted-Payment-Methods>
>
>However, because of the input from the business person, the data
>specification is translated into this implementation:
>
>    <Accepted-Payment-Methods>
>        <Method preferred="true">Paypal</Method>
>        <Method preferred="false">money order</Method>
>        <Method preferred="false">cashier's check</Method>
>    </Accepted-Payment-Methods>
>
>Note that an attribute - preferred - is added to each <Method> element
>to indicate whether or not the payment method is preferred.
>
>Thus we see an example of a business interest impacting a data
>specification and the resultant XML data design.
>
>
>QUESTION
>
>Is this revised version a legitimate example of a business interest
>influencing a data specification and the resultant XML data design?

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.