Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: loosely and tightly coupled systems and type annota tion
 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@a...] 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... 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
