Liz Fraley: This is a new blog and this is the first post. Although I’ve been an avid reader, I’ve never been an active poster on the boards or newsgroups over the years. I’ve also come and gone as a reader, looking for specific information, but I’ve never blogged before. I never really saw the point. Until now.
My intent here is to create a blog of everything I know about:
- single-sourcing: code, definition, help, documentation
- application-specific xml tools development
- practical XML development and deployment
My goal is to create a place where other people doing the same thing in other places can ask questions, seek answers, and help us all grow knowledge together.
I went from zero to 60 in about 2 seconds, so I never managed to get everything down. If you find it useful, great.
I hope that at some point there will be enough content here that someone starting out can actually get started and that the rest of us can improve what we have already done.
Setting up a single-sourcing system. It isn’t hard; it isn’t new. Yet still, the knowledge about exactly how to do it is hard to come by.
The real problem is that there are no practical resources on the subject. No books. No articles. The only way to learn it is to work for a company that specializes in doing it. This means that either you work for one of the vendors who services a part of the space or you work for one of the consulting houses that specializes in the general development side, and you learn how.
If you try to do it yourself, the closest you get to real “how-to” information are either articles by and for XML programmers or you get articles by and for managers and documentation people. The engineering books and articles give detailed explanations about how XML works, how to implement it, and XML specifications.
The documentation books and articles tell you how to use the systems effectively. Neither one tells you absolutely anything about putting the two sides together. With the documentation/manager folks, you get docbook and DITA implementation stuff, but that’s limited in it’s own way: it’s only about writing the documents with that particular DTD, not about the overall system.
The documentation that describes how to do it and what needs to be done to bridge the gap between what you get from the engineers and what you get from the doc folks is completely and totally missing.
The consulting houses count on that. Only, they don’t teach their customers to do what they do, they come in and do it for them.
I learned how to do it the hard way. It took me 10 months to come up to speed working with an independent consultant, who’d worked for one of the larger houses. She’d implemented simple systems several times. We only contracted with her for 40 hrs/MONTH. She did the beginning steps for us and answered questions for me. Basically, she gave me the breathing room to learn it. I was lucky. I learned from someone who was willing to share, early on. I was unlucky later when I had to learn the rest when I was smack in the middle of it all.
However, because I had to learn it the hard way, I decided that I’d do the same for other people that she did for me: teach people how to do it. I also decided that I’d do facilitation work to help other people learn how figure out what they’re trying to accomplish with XML and to do it successfully.
About Single-Sourcing Solutions
- We do implementation
- We do mentoring
- We do training
- We do evangelization — our Information Development Assessment can help you sell your project internally
- We help companies develop an overall XML strategy, across all kinds of business units and business functions
We also give presentations on how to implement this technology in various parts of your business (not just pubs). We hold customized seminars on how you can implement coordination between your groups based on XML technologies and fold systems together.
 Fraley, Liz (2003-10-15). Beyond Theory: Making Single-Sourcing Actually Work. New York, NY: Association for Computing Machinery. pp. 52-59. ISBN 1-58113-696-X.