It seemed to me, from the beginning, that this thread was more about analysis and design technique than about XML.  

The example given has two different data models which encode two
different sets of requirements (even though the number of requirements
is small and one set is a superset of the other).  This looks less like
"legitimate" or otherwise influence than a missed business requirement in the first iteration.  The issue in thise case is where should knowledge of which methods are preferred
payment methods live and the example does not contain enough detail to
know the answer, because there are more things to consider: information hiding (do we want to make that preferred status visible?), change management (how do you change the preferred status later?), and universal applicability of rules (is this true everywhere that the schema is visible?) are all considerations.  


Some business requirements as expressed by the users are about software implementation and some are about how the business works.  The example here might be more like the former than the latter and those are always problematic.  Absent a design objective to have the XML represent the mental model of the business users (something I think is often dangerously brittle in the face of business change), the old ANSI C committee's "as-if" rule is appropriate: if you can deliver on the core requirement you don't have to actually build the theorietical implementation model. 


Greg

On Fri, Oct 17, 2008 at 2:05 AM, Len Bullard <len.bullard@u...> wrote:

I didn't say "blind", Mike.  I said, "Not their shot to call".   I also said

they should inform the business manager about performance and I consider

improvements to design a performance issue.  It is the data designers

obligation to inform.   It is not their right to determine.



Successful businesses coordinate and inform, but unless a data designer or

any other employee understands proper authority, no business remains in

business for very long.   So again, I quibble with the question as posed.

In essence, implementation serves the business, not vice versa.



len





From: Michael Kay [mailto:mike@s...]



> 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.



Actually, I don't believe it's a good model that IT people blindly do what

the business tells them to do, and I don't believe successful businesses

work this way. If the IT people are good at implementing IT systems then

they also have the brainpower to design improved business processes (perhaps

to take advantage of IT potential, but perhaps just because they have the

right kind of thought pattern).



I remember when I was a student one of the computer science faculty members

(John Larmouth, I think) implementing a program to automate the complex

rules for University Senate elections, and ending up proposing an improved

set of rules which were duly incorporated into the University Statutes. I

think that's the way things should work.



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.




_______________________________________________________________________



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