- From: Chin Chee-Kai <cheekai@s...>
- To: xml-dev <xml-dev@l...>
- Date: Wed, 15 Oct 2008 12:04:05 +0800
On Tue, Oct 14, 2008 at 4:45 PM, Costello, Roger L. <costello@m...>
wrote:
6fa681b10810142038w3ccb5d69ha24fe72614356b99@m..."
type="cite">
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
|
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
|
Cart
