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 _______________________________________________ You are currently subscribed to Framers as [EMAIL PROTECTED] Send list messages to [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] or visit http://lists.frameusers.com/mailman/options/framers/archive%40mail-archive.com Send administrative questions to [EMAIL PROTECTED] Visit http://www.frameusers.com/ for more resources and info.
