OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] loosely and tightly coupled systems and type annota tion

[ 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 

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.


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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS