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


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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

Subject: Groups - DITA TC Meeting Minutes 14 April 2015 uploaded

Submitter's message

I've updated the minutes from Apr. 14th to reflect Kris's and Robert's comments.

1. Eliot will add troubleshooting topic to ditabase module
2. Robert will produce initial strawman definitions of peer map and submap.
3. Kris will contact Mark Myers about his work and how these definitions (of maps) affect them.
4. Chris will draft a linking topic that emphasizes the role of @scope and @forma

Minutes of the OASIS DITA TC
Tuesday, 14 April 2015
Recorded by Nancy Harrison
link to agenda for this meeting:

Regrets: JoAnn Hackos, Dick Hamilton, Stan Doherty

Standing Business
Approve minutes from previous business meetings:
https://lists.oasis-open.org/archives/dita/201504/msg00066.html (7 April 2015, Nancy Harrison)
Proposed by Kris, seconded by Bob, approved by TC

Subcommittee Reports

- 21 April 2015 meeting cancelled; no quorum due to April CIDM conference

1. Action items
- Action items from 10 February 2015
Robert: Draft new normative languages about keys and subjectScheme
Robert; think it's complete
AI; Robert will check on this
- Action items from 17 February 2015
Robert: Rewrite key definition precedence text (with input from Kris and Chris) and accommodate Eliot's concern
Robert; in progress, based on yesterday's call
- Action items from 31 March 2015
Kris and Robert: Meet to discuss linking review (Completed)
- Action items from 7 April 2015
Eliot: Implement fix for info-types in troubleshooting topic
Eliot; not yet done; will get to it as soon as I can, will also address bug reported yesterday.

2. New item: Model Document for Darwin Information Typing Architecture (DITA) Version 1.3
https://lists.oasis-open.org/archives/dita/201504/msg00062.html (Paul Knight, 8 April 2015)
https://lists.oasis-open.org/archives/dita/201504/msg00063.html (Eberlein, 8 April 2015)
https://lists.oasis-open.org/archives/dita/201504/msg00062.html (Paul Knight, 8 April 2015)
Kris; requested this last week, Paul provided a template (QWord doc, 1st hyperlink). to use. much like 1.2, but some stylistic changes

3. New item: Work required to get a working draft of the spec out
https://lists.oasis-open.org/archives/dita/201504/msg00088.html (Eberlein, 14 April 2015
Kris; first, need to decide on outputs;
- (Required) HTML on OASIS Web site (authoritative)
- (Required) PDF
- (Required) DITA in a ZIP
- CHM in a ZIP
- HTML optimized for local installation in a ZIP (see email)
For 1.3, we've discussed delivering 3 packages; base, techcomm, and 'everything'
Eliot; how about 'full package'
Bob; 'comprehensive ..'?
Robert; I like comprehensive; 'full' and 'complete' imply you need everything
Kris; let's call it 'comprehensive' for now, but try to find a better term.
[consensus on this]
Kris; so we have to update our style sheets to create the documents. looking for volunteer?
Bob; I'll do it.
Kris; would it help if you had another set of eyes?
Bob; yes, that would help.
Kris; volunteers?
Tom; I can do it
Scott; so can I
Kris; we'll be much better off if we have this done by the time we are ready to put out the spec for OASIS review

4. New item: Should ditabase include the troubleshooting topic?
- https://lists.oasis-open.org/archives/dita/201504/msg00068.html (Helfinstine, 9 April 2015)
Kris; we have affirmative responses from Scott Hudson, JoAnn Hackos, Carlos Evia, Bob Thomas
David; I noticed this, and TechComm SC approved that this should be in.
Kris; and we have approval from a number of folks; Any objections? I think this is really more of a bug fix
ActionItem; Eliot will add troubleshooting topic to ditabase module

5. New item: Question about keyref with format="ditamap"
https://lists.oasis-open.org/archives/dita/201504/msg00076.html (Anderson, 13 April 2015)
https://lists.oasis-open.org/archives/dita/201504/msg00077.html (Kimber, 13 April 2015)
https://lists.oasis-open.org/archives/dita/201504/msg00083.html (Helfinstine, 14 April 2015)
https://lists.oasis-open.org/archives/dita/201504/msg00084.html (Nitchie, 14 April 2015)
Robert; in trying to resolve draft comments in keys section, I noticed this;
"A key reference to a topicref element where the linking element specifies a format value of "ditamap" addresses the topicref element itself as though the topicref element had been addressed by ID. In particular, a topicref with a key reference to another topicref and a format value of "ditamap" is a use of the map branch rooted at the referenced topicref. [1]"
The effect of this is that you can use keyref such that if you add format='ditamap' you're bringing an entire map into that location. It doesn't seem like an intuitive result; I wouldn't advise it, and don't think processors do that.
Kris; what topic is this in?
Robert; Using keys to address DITA elements
Kris; that's a non-normative part of the spec.
Robert; but that's not obvious.
Eliot; In fact, I intended that statement to be normative.
Robert; it makes me uncomfortable if we add rules for completeness that are confusing.
Eliot; you should replace 'navref' with this
Robert; no. I would never have them replace navref with this; it's clear to them. I personally find this very confusing, and I think my users would find it so as well.
In the source it's technically non-normative, but it's not obvious when you look at the topic.
Eliot; what does it mean when you do this? in 1.0/1.1 you could ref a topicref by ID; you were addressing that topicref just like any other element. With keys, if I say anything but ditamap, it's indirect. But there needs to be able to address keyref as an object, not indirectly.
Robert; why is that? In the spec you have a key, and it points to one keydef.
Eliot; if I have a topicref that references a key, the only allowed interpretation is indirection, adressing through the key I name. Otherwise, the normal is that navigation topicrefs return keys. The spec says a reference to a key is by definition a reference to the thing that key addresses, not to the object that defines the key, unless it say 'ditamap.'
Robert; The best argument for keeping it is that it was already in the spec.
Kris; Given the fact that it was in a non-normative portion of spec, we could remove it. We need to see if the TC wants to keep it. If so, it needs to be moved out of non-normative section and put in normative section and fleshed out.
Chris; I'd argue that in the case where you want to do that, you should define a key that refers to that branch, rather than do this.
Eliot; That may be sufficient; I need to think thru that case; could be confusing, but may be sufficient.
Robert; That seems like the same level of indirection we have elsewhere.
Eliot; you may be right, I may never have considered that; I'll have to do another close reading.
Kris; what about you, David?
David; I interpreted that the same way as Robert, and we implement it that way also.
Kris; what about other processors? FremeMaker? SDL LiveContent?
[no other comments]
Eliot; I will consider the ID-based address; if I think it satisfies my requirements, I'll be OK with removing it from the spec.
[continued to next meeting]

6. New item: New definitions needed for the 1.3 spec
https://lists.oasis-open.org/archives/dita/201504/msg00085.html (Eberlein, 14 April 2015)
Kris; we need definitions for peer map and submap. Thoughts?
John Hunt; what are they intended to do? scope = 'peer' means content isn't directly available to build process, right?
Robert; basically, but it's been loosened because of x-deliverable linking in 1.3. A processor can look for target, but it's OK if it isn't there. I think it's s map that you reference using a scope="peer" and a submap is a map referenced with scope="local"
John; this may affect what some people are trying to accomplish.
ActionItem; Robert will produce definitions of peer map and submap.
ActionItem; Kris will contact Mark Myers about his work and how these definitions affect them.
Kris; in the spec, where we talk about x-deliverable linking, we're really talking about root maps and submaps.
Kris; Is there anything else on this?

7. Targeted reviews progress: January - April 2015
Schedule for targeted reviews:
Progress on branch filtering: Comments assigned dispositions; editing in progress
Processing etc.: All voting members are asked to participate
Feb 13-23: Branch filtering Branch filtering (14 pages) -- CLOSED
March 10-16: Linking Linking (10 pages) -- CLOSED; editorial work underway
TBD: Direct addressing; Keys; Keys revisited
Robert; [targeted linking review] Kris and I met yesterday, went over almost all comments, and went thru them based on content, and on 'what should this section be covering'; If anything. much of this is best practice, rather than normative, and many of the best practices aren't universally agreed on as best practices. good fodder for a white paper (I was original author of much of it] We went thru the comments, and most really no longer apply; they make suggestions about language that is really best removed. There are a few select nuggets of info that explain linking, we need to move them to better spots, e.g. discussion/definition of root map and peer map. Once we've removed excess material, we're left with x-deliverable linking. So we should rename these sections to 'x-deliverable linking' and put it in the keys section and Eliot can write it up as best practices.
Chris; that being the case, where do we discuss scope/format? we use that in DITA even without keys.
Kris; I think that content is in the 'complex attribute' section. it was never in the linking section.
Chris; I'd advocate a normative topic discussing that usage.
Kris; the question is 'who will author it and where will be put it.'
Robert; that would have been appropriate in the linking section, rather than all that was there.
Kris; are you [Chris] willing to draft that topic?
Chris; can do that; I wrote a white paper on it, I think.
Jim Tivy; Are we thinking about getting rid of linking section? Will there be be a section on it? We need a section to discuss the fact that we call it 'direct addressing.' We need a definition of what a link is in DITA.
Robert; I'm not sure, but the text that was there didn't do that.
Jimt; The section could shrink to almost nothing, but linking should exist.
Nancy; I agree that we need a topic on 'linking', since many people will look for that.
Robert; let's wait and see what Chris comes up with.
Kris; i'm pleased to see what we're coming up with around this; it took a long time, but these are good results.
Robert; the draft comments said 'what do we need to say?' and 'what are we trying to say?'
Jimt; i had questions about the use of word 'resource' and there's a URI defintion of that word, so do we need some definition of what we considera a 'resource'?
Kris; I think we have that; it came out of what we mean by resource; we have that now. when we finish having targeted reviews, we can build the processing section and have a reality check on how the individual processing sections fit within larger section. We have real limits to what we can do at this point.
ActionItem: Chris will draft a linking topic that emphasizes the role of @scope and @format.

meeting closed at 12:00

-- Ms. Nancy Harrison
Document Name: DITA TC Meeting Minutes 14 April 2015

No description provided.
Download Latest Revision
Public Download Link

Submitter: Ms. Nancy Harrison
Group: OASIS Darwin Information Typing Architecture (DITA) TC
Folder: Meeting Notes
Date submitted: 2015-05-01 08:55:13
Revision: 1

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