Ah, I miss the Haynes books so damn much. Disclaimer: maintenance documentation is more or less what pays (most of) my checks. You got a few different things h

Ah, I miss the Haynes books so damn much. Disclaimer: maintenance documentation is more or less what pays (most of) my checks. You got a few different things here that interact in weird ways when you're making books about taking things apart and putting them back together: 1) Different configurations of the thing you're taking apart - when does a "configuration" become a wholly different thing? This is something that's still not been quantitatively handled, crazy as it sounds. We have the tech, but no one thinks it's worth buying into, because there's so much money riding on the customer thinking that the product variants are more similar than they actually are. 2) What's the logical disassembly? Does the air cleaner come off before the brake fluid reservoir? Wait, the variant with the fuel injector doesn't have the air cleaner . . so maybe don't combine the airbox and brake reservoir into a single assembly for this. ETC ETC. 3) Functional systems like wiring, hydraulics - where do those go? Do you group procedures by functional system, or by disassembly order? Also: who determines what a "function" is? And of course on top of this you have integrations - do you want the handbook to "talk" to the CAD/CAM system? Wait, do you want the parts lists to come from somewhere else? Who's checking to make sure the CAD matches the PDM? And on and on and on and on. It's all good fun. Also, speaking to the original article: XML-based publishing systems are not the be-all-end-all of pubs solutions; by and large, they're a gigantic tar baby for a publications department. Now, I'm not saying that systems using XML can't be pretty neat, by integrating with CAD/PDM/ERP, but that doesn't really have anything to do with XML. In fact, intensively granular XML formats - S1000D, iSpec2XXX and MIL-STD-40051 come to mind at once - don't do a whole lot more other than lock down content to a single software vendor in a single manufacturer for just the staff of the publications department. All of the good stuff from those specs are things that shouldn't live in a document format - they should be integrated from CM, ILS/IPS, SE, ERP, and PDM. The XML itself is entirely irrelevant, and by overspecializing the schema it guarantees that each instance is going to be bespoke to every single vendor/customer/program/project. Nothing XML does can't be done in Asciidoc, for much less money, with much less work, on a generic compute platform, and using a format that can be reviewed by any jerk with a good modern text editor.