Rockley, Chapter 2 Summary - (Haupt)
This chapter focuses on one of my favorite topics in the world of documentation technologies - element reuse.
This capability first become possible when Dr. Charles Goldfarb, an IBM researcher, invented Generalized Markup Language (GML) during the 1970s. Later morphed into a more advanced implementation of structured document markup as Standard Generalized Markup Language, this invention became one of the foundational technologies upon which the World Wide Web was built. Most people do not realize the HTML is merely a simplistic Document Type Definition (DTD) of SGML. An SGML document comprises of three parts, the Declaration (for example it can specify "Transitional" HTML, the Instance, and the DTD. In the World Wide Web the DTD is never transmitted. It is retained within the browser's code itself.
For the purposes of "reuse" we focus on the DTD. The DTD is a way to describe the logical hierarchy of a document. The logical structure of a document is separated from the typographical formatting of the document (formatting is contained in a Formatting Output Specification Instance - a FOSI). When the World Wide Web was invented SGML was found to be incompatible with it unless a browser plugin was used. Therefore, among other reasons, XML was created - a simplified and web-compatible version of SGML.
XML can be used with either a formal DTD (Yes, you can code your own XML DTDs!) or a valid schema. Either approach defines logical structure of a class of documents. In the world of technical communications XML data repositories are used that contain multiple DTDs/schemas. Authors don't write documents. They write elements. An element is simply an instance of a subset of a structured document defined by the DTD. The document elements are stored within the database and are available through a front-end editor such as Arbortext. Technical Writers are able to browse a library of elements and select the ones they wish to incorporate into their document. In the event that they can't find a suitable existing element they have the option to create a new element and write the content for it.
An XML-based content management system keeps track of the element reuse, version control, audit trails, records management, security, etc. and collects the elements at publishing time. Users can specify a wide variety of output formats including HTML, TROFF, RTP, PDF, and Java Help, etc.
Additionally, publishing outputs can be customized for individual readers - pulling a subset of reusable elements from the repository for each type of need - for example an "installation" view, a "training" view, or a "maintenance" view.
Rockley correctly identifies the benefits of an element reuse strategy: 1) Increased Consistency, 2) Reduced Development and Maintenance Costs, 3) Rapid Reconfiguration, and 4) Translation.
The concept of reuse has existed for a long time but is only recently gaining large-scale traction within industry. Software developers have long used reuse of code. A Class Library is simply a collection of previously used code that a developer can reuse for new applications under development. Technical Communicators are now seeing a plethora of solutions available to meet their element reuse needs. Rockley refers to element reuse as "single sourcing". Personally, I've never heard that term before in this context. This is probably because I have approached the problem from an engineering viewpoint instead of from the technical writer's viewpoint - hence I learned the jargon of documentation engineering and have used those terms to describe the environment Rockley describes.
Rockley correctly points out that reuse is not appropriate for every document. I am currently working with Astoria Software to implement a reuse solution within Wells Fargo. Astoria provides a three-pronged test to determine if a document is suitable for reuse: 1) document must be dynamic - constantly being updated, 2) document volume must be large to meet economies of scale, 3) document production processes need to be streamlined.
In conclusion, employing element reuse solutions represent an accelerating trend in technical communications. Learn to love it!
This capability first become possible when Dr. Charles Goldfarb, an IBM researcher, invented Generalized Markup Language (GML) during the 1970s. Later morphed into a more advanced implementation of structured document markup as Standard Generalized Markup Language, this invention became one of the foundational technologies upon which the World Wide Web was built. Most people do not realize the HTML is merely a simplistic Document Type Definition (DTD) of SGML. An SGML document comprises of three parts, the Declaration (for example it can specify "Transitional" HTML, the Instance, and the DTD. In the World Wide Web the DTD is never transmitted. It is retained within the browser's code itself.
For the purposes of "reuse" we focus on the DTD. The DTD is a way to describe the logical hierarchy of a document. The logical structure of a document is separated from the typographical formatting of the document (formatting is contained in a Formatting Output Specification Instance - a FOSI). When the World Wide Web was invented SGML was found to be incompatible with it unless a browser plugin was used. Therefore, among other reasons, XML was created - a simplified and web-compatible version of SGML.
XML can be used with either a formal DTD (Yes, you can code your own XML DTDs!) or a valid schema. Either approach defines logical structure of a class of documents. In the world of technical communications XML data repositories are used that contain multiple DTDs/schemas. Authors don't write documents. They write elements. An element is simply an instance of a subset of a structured document defined by the DTD. The document elements are stored within the database and are available through a front-end editor such as Arbortext. Technical Writers are able to browse a library of elements and select the ones they wish to incorporate into their document. In the event that they can't find a suitable existing element they have the option to create a new element and write the content for it.
An XML-based content management system keeps track of the element reuse, version control, audit trails, records management, security, etc. and collects the elements at publishing time. Users can specify a wide variety of output formats including HTML, TROFF, RTP, PDF, and Java Help, etc.
Additionally, publishing outputs can be customized for individual readers - pulling a subset of reusable elements from the repository for each type of need - for example an "installation" view, a "training" view, or a "maintenance" view.
Rockley correctly identifies the benefits of an element reuse strategy: 1) Increased Consistency, 2) Reduced Development and Maintenance Costs, 3) Rapid Reconfiguration, and 4) Translation.
The concept of reuse has existed for a long time but is only recently gaining large-scale traction within industry. Software developers have long used reuse of code. A Class Library is simply a collection of previously used code that a developer can reuse for new applications under development. Technical Communicators are now seeing a plethora of solutions available to meet their element reuse needs. Rockley refers to element reuse as "single sourcing". Personally, I've never heard that term before in this context. This is probably because I have approached the problem from an engineering viewpoint instead of from the technical writer's viewpoint - hence I learned the jargon of documentation engineering and have used those terms to describe the environment Rockley describes.
Rockley correctly points out that reuse is not appropriate for every document. I am currently working with Astoria Software to implement a reuse solution within Wells Fargo. Astoria provides a three-pronged test to determine if a document is suitable for reuse: 1) document must be dynamic - constantly being updated, 2) document volume must be large to meet economies of scale, 3) document production processes need to be streamlined.
In conclusion, employing element reuse solutions represent an accelerating trend in technical communications. Learn to love it!
posted by Carl Haupt | 7:40 AM
10 Comments:
This chapter was a bit confusing for me. I do not have experience in dealing with markup language or any of the acronyms mentioned. I feel like I should have take more computer science classes somewhere along the way. Nonetheless, I think it's very important that we make a mention of this if nothing more than to make me realize that I do not fully understand reuse language and its usage. I guess I need to be more questionable of how the end result comes to be instead of just using everything and ignoring the source or original intentions behind its intentions. Actually the more I write here the more I think it may be a good idea to go back and review this chapter until I understand.
I think the Rockley book does a good job of describing the different ways content can be reused. I appreciated it being broken down the way it was. I think my view of content management was probably simplistic before reading this. I now know I have used opportunistic reuse, derivative reuse, and I’ve just been introduced to using systematic reuse; however, all at very elemental levels.
If I hadn't been exposed to the notion of content management already in my job, I think this might have been a little more difficult to conceptualize.
Carl, you really fleshed out the subject of this chapter by adding your real-life experiences. You really look it to a new level, which I found exciting and intimidating at the same time. As this class continues through May, I hope we can learn about the progress Wells-Fargo is making with the Astoria project.
I suppose this sounds like a very simple statement, but I think that content reuse is something that should be essential to any workplace that deals in documentation. Not just online documentation, but any period! When I look through all the documentation that we have on the production floor at my workplace, I just wonder how much of all this is really overlapping and repeating with what another document says. If it’s as much as I think it is, then the working hours being wasted could be staggering.
The idea of silo trap has honestly gotten me a bit paranoid lately. This concept of people all working on the same thing but not comparing notes just sounds rife with inconsistency and flaws. I think the idea of reusable content—especially when it’s accessible by many people—is a good thing. I hope that Rockley comes back to this later to flesh it our for us a bit more.
I found it interesting that the author used a manufacturing example in the reuse section. Why do you think you need two sets of wrenches (metric and SAE) to work on your car? They are using up all the old parts!
While I am not knowledgeable in the specifc methods of reuse, and I am certainly not computer science literate, I think I understand the basic ideas behind content reuse and the basic methods that are used to accomplish those tasks. Once again tables or databases are probably used, with the content of those tables and databases modified according to the needs of the users.
In my workplace, cut-and-paste is probably the most prevalent method of content reuse. Few, if any, things are tied to a centralized and updated location.
I felt that the concepts of reuse were laid out pretty well in this chapter. I had never heard of this idea before, and I was also a bit lost on the computer language that was used. I did find the different kinds of reuse interesting, especially nested reuse - mostly because the book had an example of how the information from a brochure was transferred to an e-commerce site. This little example made it so much easier for me to understand. When reading this chapter, I just kept trying to think of these concepts in forms that make sense to me, like the copy & paste idea Larry mentioned. I think I understand the general concepts, even if I don't really understand the technical language.
You'll have to forgive me, I have just gotten my copy of Rockwell and I haven't had the chance to catch up to the class in reading. So, I have only had the chance to skim and quickly read sections.
I agree that the terminology and acronym use can get confusing at times. That aside, I thought this chapter to be well-organized and helpful towards this topic. I think that terminology and acronym usage is necessary in this text, because the vocabulary used is that of the people involved with single-sourcing, and it's useful for us all to pick that up if we plan to use single-sourcing on the job.
I particularly like the concept of systematic reuse. Though this may seem like a case of lazy people 'just letting the computer do it for them,' I think that systematic reuse can greatly save the user from wasting time or incorrectly transferring information.
This chapter was a bit confusing for me as well. I am confidant that by the end of the semester more of the content will make sense. I am not, as of now, proficient in software options, it's uses, and reasons for being. Being able to understand such things will make it easier to understand as far as writing, storing, retrieving, editing, revising etc. for multiple users. I understand the concept just not the execution.
I think that content reuse is very practical for some areas. Actually arranging it to be possible is probably the biggest hurdle to this happening in a lot of places. Smaller businesses probably do not even think to try and reuse becuase of the small scale in which they publish/create. The computer stuff was a bit over my head. I wish I could understand it better but I don't see that happening in the near future.
I concur with the previous comments on how content reuse is not only a very good thing but vital for not creating more work when it is not necessary.
It's very difficult to build any sort of respectable website without XML these days. I still harbor the dark secret that I use frames and vanilla HTML. I'll have to look up XML on webmonkey to see if I can't update my skill set.
Post a Comment
<< Home