Groups - DITA TC Meeting Minutes 7 January 2014 uploaded

[Nancy Harrison<nharrison@infobridge-solutions.com>]

        Submitter's message
        Minutes of the OASIS DITA TC
Tuesday, 14 January 2014
Recorded by N. Harrison
link to agenda for this meeting:	
	https://wiki.oasis-open.org/dita/Agenda-14-Jan-2014

regrets:    Scott Hudson 


Standing Business
=================
Approve minutes from previous business meeting:
https://lists.oasis-open.org/archives/dita/201401/msg00005.html (7 January, Nancy Harrison)   
Proposed by Kris, seconded by Dick, approved by TC


Subcommittee Reports
	none

Announcements
- More presentation about DITA/S1000D Bridge
    Two presentations on 23 January 2014: 9 AM and 5 PM French time (8amPT)
    Contact jjthomasson@free.fr to register 


Business
========
1. DITA 1.3 progress
   nothing new; new artifacts in this space soon
   Trello Board: https://trello.com/b/gPKH0OcF 


2. New item: Bug in definition of @collection-type in DTD
Robert gave an overview; this and the next 2 items came up in the process of reworking the attribute tables in the spec.  The values available for @collection-type are all the same in map-based elements, but in 'linkpool' and 'linklist' there is an extra value 'tree'; this is probably pre-OASIS and never removed.
Eliot; I'm hesitant to remove it; I'd recommend we document it as 'not defined and will be removed later'.
Robert; my preference as well
Michael; this was originally a bredcrumb list of ancestors of the topic containing linkpool/linklist; whether it's worth keeping is open to question.
Don; I think we should just deprecate it.
Robert; We don't even need to deprecate it, since we never defined it.
Don; OK, but the concept, of something for breadcrumbs, bears re-addressing at 2.0
Robert; we won't define it at this point
Michael; do we want to say it as strongly as 'will remove'? Or just say 'the value is undefined and we will revisit'
Kris; so if we'll doc as currently undefined, should we add to XSD/RNG?
Eliot; if it's not in RNG, it won't make it into DTD, but I could have a special part of code that generates things like the 'longdescre'; another way would be to have it in RNG with a note on compatibility.
Kris; if we stick with policy of not breaking things, then we need to add it, either:
1. add to RNG and have it as undefined
2. add to RNG and have it as a bug
Eliot; if the issue is only the @ name in the spec, it's simple. If the bug is in the content models, it's more complicated,
Robert; it's a value for the @ rather than the @ itself, so anyone who's done their own doctype shell would have to re-implement if we changed the DTDs. My preference would be to document this as 'only defined in DTD' and reserve it for the future.
Kris; in either case, they're bugs, so we'll document them as bugs that exist only in DTDs.
Robert; I'd go with that, don't have strong preference.
Michael; I think it's a legitimate type, even if we haven't used it; but we're stuck, we need consistency and we don't have consistency in the support. So we have to document it as not supported; if we add in future, we'll add it consistently.
Robert; so we leave it only in the DTDs, document it as only in DTDs, and deprecate it.


3. New item: More attribute discrepancies - conref attributes on map
robert gave an overview; at 1.2, most elements that previously used @conref were updated to include all of the conref group of elements; conref group of attributes: conref, conrefend, conaction, conkeyref.  But on a small set of elements - map, bookmap, anchor, resourceid - the spec is missing some parts of the conref 'group, even though the DTDs/XSDs as shipped do include them. The best thing to do is to fix the spec; add the rest of the conref group to the spec for each of the elements missing them, so they'll be in sync. 
Kris; not hearing any disagreement, so we'll do that.


4. New item: Clarification about note/@type update for troubleshooting
Robert gave an overview;  for 1.3, we added a new value for 'note'/@type or 'trouble.'  The only specialization of 'note', which was done by the MI SC is 'hazardstatement'.  It includes all the other values for @type, but 'trouble' never got added; should we add it?  One perspective is that the 'hazardstatement' shouldn't even have the values for @type it already has, since they don't really apply to such a note, and so we shouldn't make it worse by adding 'trouble.'  But then it w9on't be consistent.
Don; since 'hazard' statements were for European requireements, why wouldn''t we treat the missing value in hazardstatement thing as a bug??
Kris; it would break compatibility.
Robert; It's not a bug to use them.
Kris; We should go down the path of not adding 'trouble' as a value for @type in hazardstatement; it may mean getting things out of sync, but it's not making hazard any worse than it is.


5. New item: e-mail from dita-comment list
Kris gave an overview; Red Hat wants to distribute DITA with its Fedora product, but they couldn't figure out the copyright requirements.  OASIS now wants to have comment statements inserted in all machine-readable files at every state of a draft, and they would be stage-specific.  
In light of this, Kris went to Chet Ensign at OASIS and told him 'we have 1000's of these files; will you (OASIS) insert these?'  Kris will meet with Chet & Robert on Thursday wrt this. and will report back to TC on upshot. Does anyone have questions? or want to be involved. Will need a screen-sharing web connnection?  Initial inclination is to push back on this; we really don't want to have to put these in our source files.


6. New item: DITA 1.3 proposal process: Lessons learned
    What worked well?
    What didn't work?
    How can we improve the process in the future? 
Kris: it's time to look at this; what can we do? what did we learn?
Eliot; I think it worked remarkably well; having the new requirements on the different stages of the proposals really made work more efficient.
Joann; Stan led a discussion about this at last week's TechComm SC mtg.; we noticed that there ended up being a multistage process for SC deliverables.  We'd propose a stage in there for SC proposals coming in, to have another review stage; for someone in TC to look over proposals from a technical point of view. So we could use an extra review or support from experienced TC members to SC members writing proposals for the first time.
Kris; We tried to support that, but we needed proposals to be authored by involved parties.
Robert; We either need an extra step, or have a req that there be a tech review before it comes up for discussion, at both stage 2 and 3.  Generally speaking, as the first person to integrate both 1.2 and 1.3, it was much easier to integrate; as a proposer, it was much harder, but well worth it.
Scott; It seemed like the deliverable templates were different between stages; I think it would be better if they were more consistent so you weren't having to rewrite and reformat things.
Kris; It would be good to reduce rework, but different stage templates are asking for different kinds of things.  We don't want something that can have 'TBD' or 'n/a' in them, as we would get if the Stage 2 & 3 templates were more consistent.
Kris; we'll continue this next week.


7. DITA 1.3 infrastructure and editorial work:
   Tool for conducting spec reviews
Kris; we need a tool that:
   - Enables reviewers to view spec draft and reviewers' comments together
   - Is able to handle DITA source authored in an evolving DITA 1.3
   - (If tool uses DITA-OT) Is able to easily change to a new release or patch an existing release

Does anyone have ideas on a possible tool?
Mekom has a tool thet they'd be willing to have us use.
Joann; we've been doing reviews of tools for these purposes, there are a few open source things, but the Mekom tool seems to be the best.
Chris; we (Oberon) have a tool that may be comparable; currently in pre-release, would be glad to show it to you
Kris; we talked to Chet last year about this; OASIS very clearly doesn't want to host stuff, so the agreement that was hammered out was that if OASIS won't host tools, we can go outside. BUT we have to bring back artifacts and store them in KAVI.  So we have to be able to extract and dump them, preferably human readable, but possibly just a XML dump.
Tom, Joann, Don, & Nancy want to see the tools, and are willing to commit to work on this, i.e. see demos and evaluate them against our requirements.
Chris; obviously also I'm involved.
Jim Tivy is also interested; he knows a number of different reviewing use cases; positional change, positional comment, overall comment.
There was a general discussion on reviewing tools...


meeting closed at 12:00


        
-- Nancy Harrison

Document Name: DITA TC Meeting Minutes 7 January 2014

---

No description provided.
Download Latest Revision
Public Download Link

---

Submitter: Nancy Harrison
Group: OASIS Darwin Information Typing Architecture (DITA) TC
Folder: Meeting Notes
Date submitted: 2014-01-21 00:52:39