[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Open Source XML Editor
Don't swim in quicksand. The flowing water and the action of particle against particle pull you under. Float and look for a branch or yell for help. There is a difference between specialization of human skills and decentralization of organizational management, or specialization of roles individuals play and decentralization of the parts they can play. That difference IS competence. We can call it an elite, but actually, it is pure skill and reliable, consistent knowledge. Anyone out there in business taking on new XML projects without XML experts, and XML experts taking on projects without business understanding are all screwing each other over. Be very clear because once you set these beasties, these golems in motion, they are very hard to stop and they do a lot of damage to the villagers. We are agreeing. Let's be sure this is understood. Too many people, very important people, presented XML, the semantic web, etc. as something that leads to that one button push system of Johnny fame. Rick, Simon, others are saying, wait a minute, who needs agreements, we just need to route messages (push communication down to the network protocols and consider any standardization above that local choice). This kind of message mapper might range from an organizer (inbox style) to a scheduler (Work breakdown structure type of hierarchical message routing). I am saying, fine for some kinds of work but really only where the messages are understood a priori, the communication protocol is known in advance. This newtwork level approach avoids the enterprise engineering problem the way plumbers avoid the family bathing schedule. If you don't know how much hot water you need in advance, tough. You get the forty gallon water heater because they have lots of those in stock. Discoverable systems have APIs with registered descriptions (advertised, public) for drilling down into deeper descriptions. These descriptions may be adjustable (terms and conditions) but the process is to negotiate the schedule for the route. This is the middle ground. We create a registry for services. We describe the services so others can choose the description that, in their opinion, meets their requirements. They engage in a negotiation (RFI, RFP, RFQ, BAFO, CONTRACT) and then watch the process to ensure the terms and conditions of the last piece (contract) are met. This is ontological commitment and behavioral testing. See XLang in BizTalk for one current implementation for this kind of system: choose interfaces and route by schedule. Berners-Lee says "semantic web". Gates says "frictionless economy". Sun says "the net effect". These are all just cheerleading terminology to get buy in prior to product. A lot of energy gets expended but few know what the end game is. The choices of the tools are critical, as you say. Why? Because what you allude to is what the old AI crowd used to call the competence problem. It is an uneven quality among the agents/performers/employees. The use of generic tools (as Rick points out) is applied. But how? I, perhaps others, prefer markup because a competent player can share that competence by adjusting that tool, tuning it to make a process tight or loose depending on LOCAL competence values. Even the interface between two or more companies is inherently local. But the CALS systems that worked well were sustained by the enterprise engineers. Not just MIS or IT, but people with a good overview of the tech and the business. If the tools they use, or the requirements get too complex, they are in quicksand. The water is flowing, the particles are bumping, and they thrash until they disappear. In CALS, we started out with a simple endgame: digital documentation. We discovered as we tried to achieve it that certain islands of complex knots of process (graphic to text and back) made it difficult and expensive to get to the endgame. As we untangled each knot, we found very long strands of entangled types of information, some because the information itself was complex, and some because the tool strategy made it impossible to separate the strands, to identify them or isolate them from the products that wove them together. In still other cases, we found that the personnel who understood these tools had come to a point where they considered change unendurable or unsustainable. This was for single companies executing single projects with a few subs and one customer. Now we tell the world that we can sustain a semantic web, a web in which we can describe information to sufficient detail and by such means as machine processing can be relied upon to run it while our "needy employees" do other things. <rant>Those Microsoft commercials [expletive deleted], Mr. Gates. Do something about your ad agency.</rant> It may be sustainable; it may not be endurable. We have to work that out. We understand the use of standard document types and business protocols. We understand discoverable interfaces and message routing. UDDI will work fine and then each organization gets to choose the document types ((ebXML, roll-your-own)(choose one)). But ultimately the problem of using the technology is the willingness of those who must choose and those who must use to learn the technology. We can make the type definitions/schemas as tight or loose as they want and even if some have some points of view they want to enforce (as someone said, XML writers writing about XML), ultimately the customer has to choose based on their knowledge or lack of knowledge of their own business/art/application as it is affected by this technology. That choice is the business semantic. The elite provides the means to choose the means. That's us. We do that by analysing the local conditions, tuning the technology, and when we get into quicksand, get the locals to throw us a rope. Or we disappear. Len http://www.mp3.com/LenBullard Ekam sat.h, Vipraah bahudhaa vadanti. Daamyata. Datta. Dayadhvam.h -----Original Message----- From: Marcus Carr [mailto:mrc@a...] I don't doubt that you are able to relate this to a particular organisation or circumstance that you have in mind, but for the life of me I can't draw a line between this and an operating methodology. If this can't be standardised - that is, if I have to be able to think like you - then the middle ground solution relies on elites too. I feel as though I'm swimming in quicksand.
|
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
|