Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Open Source XML Editor
 -----Original Message----- From: Marcus Carr [mailto:mrc@a...] "Bullard, Claude L (Len)" wrote: >> It's hard to outdo Oz. Munchkins are closer to the yellow brick road. :-) >Yes, I suppose that would account for them being better dancers. :-) And the gorgeous soprano voices. >> The common practice was to customize 38784 (the content >> spec - predates SGML) and use the standard indexes. The content >> sources typically were the drawings, whatever could be dragged >> out of the engineers, and the LSA data produced by the logistics >> analysts. The problem was uneven technology. Each part of the >> organization was automated independently. So? So nothing >> could interoperate without force. >Sure, but SGML addressed a lot of that problem, right? It got everyone to an >even entry point - they could at least express their own facet of the >documentation, then a programmer could organise it in the way that best suited >the organisation. (FTR, the Australian CALS used 38784 as one reference, but it >was in SGML by then - luckily, just into version D.) That would have been nice but it didn't work that way. SGML in those days was OnlyForPrintingBigBooks. The graphics folks were busily trying to grab for the top of the abstraction tree (who owns the parse), and getting any three vendors to agree on a network was almost impossible. So much IT had to be devoted to the "glue" it cost big bucks and it seldom could be reproduced. That is what CALS was about or supposed to be. In the beginning (Computer Aided Logistics) CALS was close to being an "even entry point" in that there were just three of four standards and some flexibility for implementation. Basically, it was a file forward lobster trap system. By the time it became Commerce At Light Speed four billion dollars later, it was such a hodge-podge of options, no one wanted to fool with it. Along came the web with No Options (HTML - love it or leave it) and things moved again while the three decades of markup development repeated. It is like rock: from three-chord blues to jazz every generation, then a collapse of unsustainable complexity back to unendurable simplicity. It is a cycling learning curve driven by the ratio of experienced users to newbies. >I agree that the data needs to be managed at an enterprise level, but that need >not be a reflection on the tools or people. We did plenty of defence projects >>with non-standard DTDs - there was no value in teaching a markup team the whole >of the CALS syntax in order for them to mark up interviews (for example). You >infer that everybody needs to understand and adhere to the big-picture >requirements of the organisation - I'd rather see it layered more. Heavens, I am not suggesting everyone learn everything. That is what the collapse is about. But not having an overview of the automation of the enterprise also has penalties; noise at the interfaces. No, I've said this again and again here: de-centralize. That model uses resources better. That doesn't mean, don't manage resources. Choose the means to choose the means. The critical choice in community formation is the choice of the process of governing choice. >> > All this on top of the fact that their fundamental purpose is >> > to act as a subject matter expert. >> >> My career spans that period. I had to stand behind the mule and push. >[Obvious analogies about carrots deleted...] Mules don't care. That is what makes them mules: don't bet on rationality. Bet on hunger but it means waiting. >> 1. Some want the IT department out of the loop. If the tools require >> that much CS, than Word it is with IT in the afterloop of the document >> cleaning up the exported information. WYSIWYG rules if one can't >> hack a schema and a stylesheet. >Back to typing galleys? I think that's too far back. Not typing galleys: Word with an exporter. Ugly, noisy, and without the strict structures of a decent schema or DTD. If you want freedom and a good look, there you have it. How strict one designs depends on the content type. The rest is politics. >> 2. If IT is in the foreloop, then they should be setting up products like >> XMetal. I have to assume they are good plumbers capable of following >> the flow through the building. Automating one department at a time without >> seeing the whole picture just repeats the same mistakes of the 70s and >> 80s. >It's possible to see the whole picture without implementing it all at once or >all one way. Managing modularity is nothing new to any organisation, as long as >the base is fairly firm and the direction is clear to those who need to know it. >This approach gets my money. You are betting on rationality. That would be nice if possibly boring. I am betting on competition and self-interest. Self-interest is a steerable engine. Shape it toward enlightened self-interest such that the individuals understand the requirements of the whole picture. I don't think elites always make the right decisions; I concede there is a natural tendancy for organizations to evolve toward them. The middle ground is to ensure the system for choosing the means to choose the means is a layered communication system, not so tightly defined that it can't evolve, but not so loose that evolution is by catastrophic emergence. Ummm.... peer to peer, centralized backup, or generic peer to peer? len 
|
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
|
|||||||||
