dita — archive
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]
RE: [dita] Groups - Proposal 13102, Stage 2 Release Management (PDF) uploaded
Hi there, I had a couple of additional items that I hope you can clarify: · In the requirements list, one of the requirements is “function responsible for validation”.
In reviewing the proposed support, I didn’t see any specific element that seemed to support this requirement.
Is the requirement that you be able to identify the organization or person who validates the change?
Or is there some other intent?
· Did you consider the requirement to identify the person or group requesting the change?
In cases where there isn’t a formal system with an ID, this could be useful.
· For the date support, is there a specific intent for the separate elements?
For example, is the <change-started> to indicate the date the change was made in the file and the <change-completed> to indicate the date it was validated?
· In the requirements list, one of the requirements is “regulatory-relevance”.
In reviewing the proposed support, I didn’t see any specific element that seemed to support this.
Is the intent that you would enter this in the summary?
Thanks for your assistance, Amber
From: Amber Swope [mailto:[email protected]] Sent: Friday, August 30, 2013 1:53 PM
To: 'Tom Cihak'; '[email protected]'
Cc: Seraphim Larsen ([email protected])
Subject: RE: [dita] Groups - Proposal 13102, Stage 2 Release Management (PDF) uploaded Tom, I reviewed the proposal in light of my clients’ requirements and really liked the way you propose to handle the multiple-product/concurrent release challenge. Overall, I think that the strategy of using the topic <prolog> and the structure of the domain are sound. However, the one item I didn’t see addressed is the requirement to visually indicate the exact location of the change in the content of the topic. It seems to me that the <change-item> needs to reference the modified element and it comes down to the selection of the appropriate DITA referencing mechanism. Has the subcommittee considered the options for providing this support? The challenge for many teams is the they need to visually indicate changes between releases of a deliverable, but the track changes features in most tools don’t work for the following reasons: · author may want to identify a subset of content changes based on specific criteria, such as importance or relevance · changes may not correspond cleanly to the workflow versions/revisions of the topic file and the releases of the deliverable Thanks and have a great weekend, Amber Amber Swope dita specialist <dita strategies> 503.922.3038 [email protected]
From: [email protected] [ mailto:[email protected] ] On Behalf Of Tom Cihak Sent: Friday, August 23, 2013 1:34 PM
To: [email protected]
Subject: [dita] Groups - Proposal 13102, Stage 2 Release Management (PDF) uploaded Submitter's message PDF version of release management stage 2 proposal
--
Tom Cihak Document Name : Proposal 13102, Stage 2 Release Management (PDF)
Description Proposal 13102, Stage 2 Release Management PDF Download Latest Revision Public Download Link Submitter : Tom Cihak Group : OASIS Darwin Information Typing Architecture (DITA)
TC Folder : Drafts Date submitted : 2013-08-23 13:33:50
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]