[
Lists Home |
Date Index |
Thread Index
]
Good.
http://hbsworkingknowledge.hbs.edu/item.jhtml?id=4318&t=leadership
There is a snarky habit on some lists and in some discussions of
dissing the XML-Dev habit of debating issues, some even non-XML
related. XML-Dev is one of the most consistently useful and
informative lists precisely because of this.
1. The designer has a variety of options of where to put
business rules. Are business rules semantics?
2. What situational aspects determine where it is best to
put these? Some will argue that it is seldom best to put
them in the schema because in a data-centric system, business
rules act as the interpreter of the data and given several
independently managed vertical semantic stacks, the first
order of business is to ensure shared data is recognized,
and then handled.
DTDs were successful because they did less of the latter.
XML Schema, applied without some notion of independence,
does too much of the latter. RELAX NG is more constrained
in what it can do, so it artificially restricts this
application. However in all cases, it is not the
technology but the application design that is in
question.
In CAD-to-CAD communications, we find that keeping the
shared data description as simple as possible and avoiding
the issues of command and control work best even though
dispatch is essentially a command and control application.
This is the distributed vs centralized issue that comes
up again and again in the 911 hearings and in most
situated network designs. Collaborative networks have
aspects that are similar to the problems described in the
article cited above.
len
|
