Sounds good to me. Let’s make this our recommendation to the TC by adding it to the proposal.
From: Bob Thomas [mailto:email@example.com]
Sent: Monday, June 10, 2013 12:36 PM
To: Park Seth-R01164
Cc: DITA Tech Comm SC
Subject: Re: [dita-techcomm] RE: OASIS DITA TechComm Subcommittee-- Meeting Monday 10 June
I have some thoughts regarding the date and time question. Unless we have a compelling reason not to, we ought to follow the XML Schema text format for DateTime data type. Here is an example of that from the W3C recommendation:
2002-10-10T12:00:00-05:00 (noon on 10 October 2002, Central Daylight Savings Time) is equivalent to 2002-10-10T17:00:00Z (UTC, which is the same as GMT when daylight savings time is not in effect)
On Mon, Jun 10, 2013 at 9:59 AM, Park Seth-R01164 <R01164@freescale.com> wrote:
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.
"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.
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.
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,
710 Kipling Street, Suite 400
Time zone: Mountain (GMT-7)