Precisely. And if there are working examples, platinum. What we are
seeing in industry is a dearth of well-trained technical writers who
are past building their hiking club's web page, or using templates and
actually can read and apply a specification using the tools at hand.
Instead we get wine connoisseurs who know excel and word, who have
been shown DITA at a seminar but who have never opened 40051 or S1000D
and proudly tell us in meetings no writer should ever have to know
about nodes, validation, why well-formedness is important or the
difference between XML syntax and XSD.
And then an HR problem becomes a technical problem. I read an
O'Reilly article about the release of the Affordable Care Act system
in the US that was on point in one respect: policy people are not
technical and if the problem at hand is technical, you can't let them
run the meetings. On the other hand technologists tend to be
fad-oriented, insular and only capable of working problems that
compute so when it comes time to budget for tools they do not
understand that yet another six month license at exorbitant costs for
support for a tool that adds nothing but flavor is a bad choice when
the tools at hand are still doing the job. Sounds Good Maybe Later
(SGML).
Next week, marshaling; this week, transforms. Because the main thing,
in fact the only thing, is delivery of quality product in accordance
with the contractually obligated specifications. Everything else is
bullshit and while bullshit may have a place in the front office, here
where bytes must change state before anything happens, as Dr. Goldfarb
said, we need less of that.
Now back to this XSLT I'm debugging because for some tasks, it is golden.
