Lists Home |
Date Index |
From: Roger L. Costello [mailto:firstname.lastname@example.org]
>Yesterday Len Bullard made a similar statement:
>> ... most fundamental errors are ... to consider only a single schema.
Even if one thinks it easier to manage a single schema, command and
control in adaptive systems is distributed. A schema is a control.
Sometimes it is useful to have one control: think old TVs with
volume and channel selectors. Sometimes, to be flexible with
respect to a variant environment, it is better to have multiple
controls. Think of component stereos with equalizers, filters,
etc. Rick J. nailed it: variant and invariant conditions. Just
remember, this describes not only the system, but the hosting
environment as well. A self-directed evolving system monitors
changes in the environment and adapts to them. This is also
known as event-based notification.
> ... fall into the trap of thinking of THE schema and not
> recognizing the system as a declarative ecosystem of schemas
> and schema components.
Not should, but can be and often is. If these are isolates, it
doesn't matter much how singular or multiple they are; but when
they are in an ecosystem, they typically overlap and exchange
information, and adapt as a result. That is why the emphasis
is on ecotonal relationships, eg., where tundra meets forest
what species do we find.
>It would be very useful if we could have a simple example that shows how
>several schemas might be employed, rather than a single schema. Could
>someone provide an example?
Look at any large reporting system. You can build that up a large schema
but given local variations, do you have sufficient power/force/authority
to make them stick or will you be constantly adjusting them, loosening
them, strengthening them, and how will you know which is the right
thing to so? It is of little use to be aware of context unless you
have some means to determine what is important in the context relative
to the goals of the transaction. The example of the Draconian parse
rule is a good one: in what situations should it be relaxed?
>Len, I like the term you used, "declarative ecosystem". Could you
>upon what this means?
It means declarative definitions that overlap in a dynamic messaging
It can be random and exhibit behaviors like Brownian motion, or aware and
directed, or simply patterned. The essence of intelligence is not
but self-directed adaptation. An intelligent system learns. It not only
memory, it has a goal seeking behavior that can use memory to more
select behaviors. It is not trapped in the past. It speaks the future into
> ... most fundamental errors are to consider schemas only at the external
> system junctions ...
The problem of locale is that it is declared locally but might require
global management. Think of the British mail system vs the American
mail system. The American system is far more efficient. The British
system is more colorful. It is easier to send mail in the US. Size
matters. The Brits can use a system such as MI5; the Americans can't.
The problem is the numbers of active interfaces being routed to one
or a few receivers. Sometimes, a single schema suffices for the whole
system. Sometimes, you needs lots of little ones. The reasons may be
scale or legacy (the way in which it grew and the decisions made for
local reasons forced to the top as global policy). The reality is that
social decisions matter. We engineer to these until the system decides
it can't afford that any longer. Then we see standards with teeth or
small groups breaking off and creating keiretsu: think Intel + Adobe,
or Sony + whoever. Should I use ArcXML because ESRI dominates the
market and supports proprietary dialects, or should I work hard to
get ESRI to support GML because my customer demands open standards?
Should I slow the system down with XSLT? Should I use IE because
MS won the desktop hegemony?
I can't separate social rules from engineering fundamentals. I
apply engineering fundamentals to implement social rules.
No size fits all.