RE: Open Source XML Editor

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

-----Original Message-----
From: Marcus Carr [mailto:mrc@allette.com.au]

"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