[
Lists Home |
Date Index |
Thread Index
]
Principle of Least Action: find the most sensitive part of
the system and use the least amount of force there to create
a self-sustaining series of changes.
1. XML specifications are becoming complex because XML
is being applied to different problems. In SGML, we considered
markup *generally applicable* but the real application and
application projects were widely separated and organizationally
loosely coupled (not the designs, the projects and people
themselves). Now we are using the Internet to describe
and discuss aspect of projects with widely diverging requirements.
Our synthetic systems and our social systems interact and create
complexity.
2. Our social systems for coordinating these use overlapping
and conflicting terminology to achieve overlapping and conflicting
goals among different polities. The most blatant example is confusing
community created (eg, W3C) specifications for standards. The
unwillingness to admit that a specification is not a standard
has been shrewdly used to authorize constraints and to confer
authority over communities that the specifications themselves
do not justify. The simple rule of "rough consensus and
running code" works at low densities of interacting contributors
and authorities but falls down at the densities we are now
seeing. Scale is not a simple value of "large and larger"; it
also applies to "dense and denser".
Given these conditions, the complexity of the current XML frameworks
is inevitable, but it does not mean that this condition remains constant
over time and across overlapping systems. CAREFULLY study the
conditions and relationships that emerge and determine if any of
these can be relaxed, tightened, or altered. Choose wisely.
As long as the core XML specification remains as simple as possible
(and one can debate that endlessly), there remains the opportunity
to create both the kinds of simpler systems Simon prefers where
all of the semantic choices remain local, and the kinds of complex
systems the XML strongly-typed database systems supporters are
building. But the desire to enable and sustain blind interoperability
among systems built by these two camps will be met unevenly whereever
these systems overlap. That is also something we will have to accept
because of the nature of the social systems themselves. We will
commit a far more egregious error by trying to correct that at large
or by fiat. The call for the "strong man" will grapple with the
application of rule by empowered committee and these will both
turn on the small groups of independents. In short, it will look
like the frats taking on the GDIs taking on the administration at
a university campus riot.
There isn't an out. There is the practice of cool headed analytical
cooperation and occasional flights into rhetorical legerdemain.
The thing we perceive as a mess a) may not be as bad as it could be
and b) is a natural consequence of the problem and the means and ways
by which we have been solving problems. In short: SNAFU where the
first two terms really are, "Situation Normal".
We can take a page from HTML history and try to identify a least
commitment principle for XML systems builder: a sort of mimi-me
architecture that says, to hook up two systems that wish to cooperate
on closing some set of transactions, this is the least one can do
to still have predictable interoperation. I suspect that will look
a lot like REST with DTDs, minimal use of namespaces if any, XSLT
and ASP-like scripting. This is something I believe the TAG is
empowered to consider as principles of architecture although the
practical result might be a straw system spec based on those principles.
Everything else (including security), is gravy from the stew. There
are few universal recipes for stew, but we always seem to recognize
stew when we smell it or eat it. And there is no accounting for
tastes, so we accept a menu of options and tolerate those dining
with us in the same restaurant, and sometimes, at the same table.
len
From: Marcus Carr [mailto:mcarr@allette.com.au]
Bullard, Claude L (Len) wrote:
> I realize that, but I've never been able to
> find a way to stop a stampeding herd. If it
> is following a leader, then at least that
> is the person who's direction can be changed.
Continuing the analogy, there are two problems with that approach. The
first is that by the time you've worked your way through the herd,
(reasoning your way past all of the others who believe just as
passionately in their own views) and convinced the lead buffalo that
you're right and it's wrong, you may find yourself girt by sea.
The second problem is that although even the lead buffalo believes that
it's leading a single unified herd, in this case it's actually a number
of smaller herdlettes running together. Each herdlette has it's own less
obvious leader steering a portion of the group in a slightly different
direction. For those common herdmembers who are certain of whom they
wish to follow, this isn't an issue. For some though, the choice is less
obvious, resulting in confusion and fragmenting of the whole along
specific and predictable lines.
> The W3C has a Director. At various times, I
> have come down hard on that position, but an
> honest fellow holds it. Start there.
I don't think anyone's questioning his honesty. The point is that the
more diverse the uses for XML are, the less anyone can claim to have a
comprehensive grasp on it. This is particularly true when the evolution
impacts on a field outside one's own experience. Unless TimBL has a
capacity unmatched by anyone that I know, he will be relying more on the
opinions of others than he used to. That means that if we see a trend
toward a direction that we don't agree with, we should speak up, making
it easier for him.
> What technical requirements have lead to the
> complex morass of interlocking specifications?
You'd have to define "technical requirements". I think that the problem
is that XML is being pulled in different directions. Some features could
be defined as technical requirements of the industry doing the pulling,
but I'm not sure that you can call them "technical requirements of XML".
I'd classify them more as "useful features for a specific profile of XML".
> Stew left to stew goes bad fast.
Ahh, at last, the inevitable fate of the herd...;-)
Stew made with my favourite ten foods smells bad as soon as it hits the
heat. Perhaps it's the tunafish reacting with the milkshake. It's hard
to fathom though, when they're both such fine foods in their own rights...
|
