anticipating a move to Structrued Frame

[mcarr at allette.com.au]

Fred said:

> But the point remains that the best way to prepare depends greatly on
> what your goals and objectives are.

... and went on to make several other excellent points.

John said:

> I think the single biggest obstacle to my adoption of Structured
> FrameMaker has been exactly this sort of discussion. I have searched
> and searched and failed to find a straightforward high-level doc that
> tells me what the project is based on my business needs.

That's because structure is a toolbox, not a product. If it was a product
it would be fair to ask "how do I use it?", but it's not fair to decry a
toolbox because it has no manual describing what it can fix. If you don't
understand what you're trying to fix, then get a mechanic. (Okay, I've
worn out the metaphor.)

I recommend that people get a consultant for this stuff not only because
I'm occasionally a consultant, but because in 15 years of SGML and XML
projects, I've seen endless heartbreaking failures.

> All I need is an article that introduces the various concepts and tells
> me which structure concepts belong in my project and which I can safely
> ignore for now:

In order to establish which concepts belong in your project, you need
first to evaluate the requirements and capabilities of your organisation,
for example:

 o the capability of current staff, as well as the will to replace them
   if required,
 o the long-term requirements for data handling and use,
 o migration strategies from current systems,
 o ROI,
 o evaluation of emerging technical directions in data management,

These are corporate decisions - once you get them sorted out, you could
start looking at which concepts belong in your project, but as I'm sure
you'd appreciate, the value of the advice is diluting quickly based on the
corporate uncertainty.

> Structured authoring can do many things. Here are some case studies.
>
> Alice needs A; here is an effective solution for A, using DITA.

If it was that easy to decide on a strategy, then we wouldn't be having
this discussion. The reason that these articles don't exist is that anyone
with sufficient experience to write one knows that it would be
irresponsible to do so. It would mislead people.

Here's a real-world case study:

The Australian DoD was in the market for some new helicopters. They
settled on the Tiger from Eurocopter. One attraction was that the
documentation would be delivered in S1000D format - a standard for
SGML/XML data that the Australians are also very keen on. Perfect fit,
right? Pretty much, except that there were a couple of discrepancies in
the data. S1000D provides for modules to be nested at various depths. The
Aussies settled on two depths but the portion of the data that came from
France was nested to three levels, requiring transformation to try to
shoe-horn into two levels. Oh yeah, after they translated all of the text
out of French. Yep, they forgot to agree on the language that it would be
delivered in.

Saying that Dennis used DITA and Doris used DocBook is about as useful as
saying that "today it's sunny in both Honalulu and Antarctica". It's the
details that kill you.


Marcus