[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Open Source XML Editor
- From: "Bullard, Claude L (Len)" <firstname.lastname@example.org>
- To: Marcus Carr <email@example.com>
- Date: Thu, 15 Feb 2001 08:21:09 -0600
From: Marcus Carr [mailto:firstname.lastname@example.org]
"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
>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
>the organisation. (FTR, the Australian CALS used 38784 as one reference,
>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
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
>not be a reflection on the tools or people. We did plenty of defence
>>with non-standard DTDs - there was no value in teaching a markup team the
>of the CALS syntax in order for them to mark up interviews (for example).
>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
>> XMetal. I have to assume they are good plumbers capable of following
>> the flow through the building. Automating one department at a time
>> seeing the whole picture just repeats the same mistakes of the 70s and
>It's possible to see the whole picture without implementing it all at once
>all one way. Managing modularity is nothing new to any organisation, as
>the base is fairly firm and the direction is clear to those who need to
>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?