TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
RE: Managing "comments" in XML documents like any other XML conte nt
Subject:RE: Managing "comments" in XML documents like any other XML conte nt From:"Nagai, Paul" <pnagai -at- inovant -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 13 Nov 2003 08:06:50 -0800
> But in the spirit of XML, you'd need to create a different comment tag
> for each type of comment you want to store, depending on the purpose of the
> comment.
Or use attributes on the comment tag (author, date, audience, ... the possibilities are endless!).
We use both an element <remarks> and <!-- "regular" comments --> for different purposes. The function of each strategy interacts with our editor, Arbortext Epic. For example, Epic can show/hide <!-- comments --> through the out-of-the-box interface. They can be printed via PrintEditorView but are not PrintComposable. Through the use of a stylesheet (FOSI or XSL) we have much greater control over the behavior and presentation of <remarks> element in Epic (FOSI) or outside (XSL) than we can have with regular comments. We can format, show/hide, change font, color, etc. through the stylesheets.
We haven't implemented this, but I think we will eventually want to support at least an audience attribute on <remarks>. audience=authors would not express the contents of <remarks> in any of the output intended for customers. audience=customer1 would express to customer1, but not customer2. audience=reviewer2 would ...
The biggest risks, I think, are that once you decide content in audience=reviewer2 will only be seen by reviewer2, you must be very sure of your systems. Bugs or failed process the "releases" information incorrectly can potentially be very expensive in actual $, credibility, etc. Second, every degree of complexity raises the training costs, risk, etc. associated with a system. If you have lots of authors and lots of reviewers and lots of customers, the starting and sustaining the proposed system above will be real work.
RoboHelp for FrameMaker is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to online Help, intranet, and Web.
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! Call 800-718-4407 for
competitive pricing or download a trial at: http://www.ehelp.com/techwr-l4
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
