OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita-techcomm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: OASIS DITA TechComm Subcommittee-- Meeting Monday 10 June

Some notes from the call embedded.


Action: Stan, JoAnn, and Seth to discuss transition of Co-Chair role to Stan. We will get the Trello cards updated with the current state of this proposal.


Targets: Hash out content model changes via email, be ready for TC agenda item next week (not containing the processing requirements). Hash out processing requirements and be ready to return to the TC later in the month with complete proposal.




From: dita-techcomm@lists.oasis-open.org [mailto:dita-techcomm@lists.oasis-open.org] On Behalf Of Park Seth-R01164
Sent: Sunday, June 09, 2013 8:59 PM
To: DITA Tech Comm SC
Subject: [dita-techcomm] RE: OASIS DITA TechComm Subcommittee-- Meeting Monday 10 June


Thanks for providing the attachments, JoAnn.

Regarding the Release Management proposal, here are my review comments for the document Tom submitted before the holiday (https://www.oasis-open.org/apps/org/workgroup/dita-techcomm/document.php?document_id=49080&referring_url=%2Fkws).

  • The content model shown in the image is not complete. Need to add:
    • "change-request-reference" (or whatever we decide to call the element which will provide traceablity to an external change request or other ticketing system)[Park Seth-R01164]  Decision: will add
    • "machine-time" as a way of stamping changes with a tool without the use of the month/day/year construction[Park Seth-R01164]  Decision: will add as alternative to “human time”
  • The following are not in the data model, and I dont think they should be, because they make up a very specific industry need. We should say that we're aware of these examples of needed extension points and explain that "data" is provided to enable further vocabulary extension: [Park Seth-R01164] Decision: omit from content model; use data specialization if needed.
    • product group
    • regulatory relevance
    • functional area
  • Question: The Machine Industry summary section in the wiki requests, "localization required -- yes/no"; what is this? [Park Seth-R01164] Decision: we think this can be handled with “normal” DITA translation processes (@translate)
  • What do we want to say about "time" in the spec? For publishing purposes, will we need/use this level of precision?[Park Seth-R01164]  Decision: prefer to leave to implementation; will ask the TC for guidance.
  • Should we link to the wiki (https://wiki.oasis-open.org/dita/ReleaseManagementWiki)?[Park Seth-R01164]  Decision: No, the proposal is now the authoritative definition.
  • Need description of how the revision history roll-up would occur. Key points: [Park Seth-R01164] Decision: needs to be much better fleshed out and described.
    • Change information stored in topics with time information
    • Bookmap would include new "frontmatter/generated-list/revhistory" element, which will contain elements [currentRev,previousRev, (year,month,day,(time,timeZone)|(machinetime))|machinetime][Park Seth-R01164]  Decision: this is relatively new, so it needs more review.
    • The revhistory element may contain a "copy-to" attribute. (more information to follow)
    • More than one revhistory containers normally occur, users will need an option to determine whether to produce a full, running revision history, or whether to report only the changes which occur during a subset of releases. This is probably best handled with a build-time parameter. We can omit this complexity, but at the very least need to encode the currentRev and previousRev information so that a record of the time ranges used to generate revhistories is stored somewhere. Unused set can be filtered out or commented out.
    • Like indices, processing will need to comb through all topics and pull out all changehistory items that meet the criteria after link resolution and before filtering.
    • The copy-to directive will create a DITA file during early processing. User should be able to retrieve this file. In some cases, a user may initiate processing purely for the purpose of generating this DITA file, which may be modified and run as part of a build that calls it specifically, rather than building it through copy-to.
    • Would be nice to have a new select-att (called "changeID") as a way of relating the ID of an entry in the change-list to any element which is impacted by that entry. Processing could generate some visual clues as to what areas of the content were impacted as a result of the change as described in the change-item. This attribute would be used only for flagging, like @rev. This functionality may be achievable with @rev if a SubjectScheme is properly configured. Have not tested.

I think after we address these issues, we'll be able to move this into the review stage.


From: dita-techcomm@lists.oasis-open.org [dita-techcomm@lists.oasis-open.org] on behalf of JoAnn Hackos [joann.hackos@comtech-serv.com]
Sent: Saturday, June 08, 2013 1:54 PM
To: DITA Tech Comm SC
Subject: [dita-techcomm] OASIS DITA TechComm Subcommittee-- Meeting Monday 10 June

Hi All

We are back for a crucial meeting this week. We need to do a final review of the three Troubleshooting Proposals that Bob Thomas and I have been working on. I've asked Bob to send the revised Stage 3 proposal to everyone by the time of the meeting.


I've revised the Troubleshooting elements topic from Kris Eberlein's comments. I've also modified General Task, Strict Task, and Machinery Task topics from the architectural specification. And, I've added a note to the Task Troubleshooting Stage 3 proposal (at least the last copy I had locally) that indicates I've added these topic changes and recommend where the new Troubleshooting Elements topic should be place.


Please look these over by Monday. Bob should also send everyone a new copies of the Step, Note, and Task Troubleshooting proposals.


I hope Bob will have a report on the Troubleshooting topic for the meeting.


I also hope that we have an update from Seth and Tom on the release management proposal.


Please read the new topics enclosed here and be prepared to offer any feedback at the meeting. I'll ask for approvals so that we can move these proposals through the Stage 3 approval vote at the TC.


Thanks for all your help,



JoAnn T. Hackos, PhD


Comtech Services Inc.

710 Kipling Street, Suite 400

Denver, CO 80215





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]