That isn't an example of "a business interest influencing an XML data 
design", that is an example of inappropriate interpretation of a user 
requirement. It is common for users, and subject matter experts, to 
be unfamiliar with the layers of an application, and thus for user 
interface requirements to be expressed as something else, in this 
case, data design requirements. The appropriate thing to do when a 
user requests expressing something in an inappropriate layer is to:
   - make sure you understand the real requirement, and that the user
      knows you understand it,
   - document the requirement,
   - pass it on to the people designing the layer where that is an
       appropriate request
   - explain to the user where this request should be handled, and why,
   - make sure that the data design is rich enough to support creating
      the user interface the user seems to be requesting.

This takes longer, in the short run, than making the inappropriate 
design that has been requested, but is worth the investment not only 
becuase this piece of the design will be better but also because the 
whole process will improve as everyone involved is educated.

-- Tommie



At 7:45 PM -0400 10/14/08, Costello, Roger L. wrote:
>Hi Folks,
>
>Below is an example of a business interest influencing an XML data
>design.
>
>
>QUESTIONS:
>
>1. Do you agree with my example? Would you revise it in any way?
>
>2. Can you think of another simple, compelling example of a business
>interest influencing an XML data design?
>
>
>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>
>
>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>
>
>Thus we see an example of the influence of business interests on XML
>data design.
>
>/Roger
>
>
>_______________________________________________________________________
>
>XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>to support XML implementation and development. To minimize
>spam in the archives, you must subscribe before posting.
>
>[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>Or unsubscribe: xml-dev-unsubscribe@l...
>subscribe: xml-dev-subscribe@l...
>List archive: http://lists.xml.org/archives/xml-dev/
>List Guidelines: http://www.oasis-open.org/maillists/guidelines.php


-- 

======================================================================
B. Tommie Usdin                        mailto:btusdin@m...
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                           Phone: 301/315-9631
Suite 207                                    Direct Line: 301/315-9634
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
   Mulberry Technologies: A Consultancy Specializing in XML and SGML
======================================================================