OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Open Source XML Editor

"Bullard, Claude L (Len)" wrote:

> >Perhaps the SGML versions of your MIL specs didn't mimic common
> > practice as well as our 5629A initiative did in Australia...:-)
> 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. :-)

> 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.)

>  The WinHelpers are hanging
> on to tech that makes it easy to build the contentIDs and
> the full-text-indexing.  HTMLHelp fixes that but doesn't
> improve the product.  Really, they need to manage
> enterprise data with tools capable of spanning the business.
> Few people understand their own business well enough to do it
> and when they do, the rice bowl resists change. Nothing new in this.

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.

> > 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...]

> 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.

> 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.

> 3.  I can perform their job.  Mine isn't that hard to learn either.  It is
> in fact, easier than it has ever been because we are pulling the mule these
> days.
> It's a fresher path out front.

I'm quite sure that you are one of those people who can span both, but there
aren't many like you. It's not going to fix things if we expect people to
develop such diverse skills either. (An industry riddled by clones of Len? Head
for the hills!)


Marcus Carr                      email:  mrc@allette.com.au
Allette Systems (Australia)      www:    http://www.allette.com.au
"Everything should be made as simple as possible, but not simpler."
       - Einstein