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: Minutes from 18 June 2019 TC meeting


Minutes of the OASIS DITA TC

Tuesday, 18 June 2019

link to agenda for this meeting:

 

ACTION ITEMS:

1. Kris to send out PDF of topics to start looking at.

2. Robert to answer Chris Papademetrious's emails.

3. Robert to set up submodule for Tech Comm.

4. Robert to look at stylesheet issues. You can pass these on if we have another volunteer.

 

1. Roll call

Attendance: Zoe Lawson, Dawn Stevens, Kris Eberlein, Bill Burns, Robert Anderson, Stan Doherty, Alan Houser, Eliot Kimber, Keith Schengili-Roberts, Chris Nitchie, Deb Bissantz, Jim Tivy, Joyce Lam

 

Regrets: Tom Magliery, Carsten Brennecke, Scott Hudson, Carlos Evia

 

2. Approve minutes from previous business meeting:

11 June 2019

 

Moved by Kris, 2nd by Bill Burns.

 

4. Action items

Several overdue. Kris encouraged everyone to see what can be done to finish these.

 

5. Meeting on 25 June 2019.

Already have regrets from Robert Anderson, Kris Eberlein, Tom Magliery, Bill Burns, Chris Nitchie, Scott Hudson

Kris will cancel next week's due to number of members out.

 

6. DITAweb review of multimedia domain topics

Alan Hauser set up accounts for Joyce and Zoe. Ran into some glitches with DITAweb. Thinks there is some path error. DITAweb is looking for a map at the top level of the repository. Alan might go to Congility for help. Kris recommended setting up a new map at a higher level in the repository for the Multimedia topics. Going forward, we are going to need to review maps at this level in the future. Kris offered to provide help.

ACTION ITEM: Kris will send out PDF of topics to start looking at.

Reviewers are encouraged to review the PDF first and then add comments into the DITAweb review tool.

This review should focus on resolving the draft comments.

 

7. DITA 2.0 stage two proposals

Robert discussed proposal #217: Removing domains attribute. This attribute is no longer fulfilling the needs it was originally designed for. The proposal removes the attribute, all tokens required by specializations and constraints. There are some tokens that cannot be removed, since they are related to attributes. Attributes don't have @class. Attributes have another mechanism for specialization. For this reason, the proposal adds a new attribute named 'specializations' based on Chris Nitchie suggestion, for future use cases. Tokens for attributes have been simplified for this proposal, using a simplified syntax, similar to the @class syntax. Attributes specializations begin with @ and are separated by a /. One token that is simplified. Setting up for generalization in the future.

Alan: Does anybody actually specialize attributes. Kris and Robert: absolutely. The spec specializes attributes. Eliot: I know of an example of more than 200 specialization of @props. Alan: I know specialization of attributes is common, but I was asking if anybody is specializing specializations of attributes. Do we need to add support for this if it is not common? Robert: Adding it, doesn't cost anything, so add it. We did use this to support the grouping attribute in DITA 1.3.

Alan: is there any relationship between this proposal and the ability to constrain attribute specializations in DITA 2.0. Robert: I think a little. Chris N. is the champion for that proposal and also reviewed this proposal.

Kris: any other questions, thoughts, comments.

Alan: The @ leading the full string as opposed to leading each specialized new thing, are we okay with that or should we have a @/ before each specialization. The @ sign means we are specializing, I don't think we need more. The @ means we are specializing attributes.

Kris: we will move this for a vote at the next meeting.

 

Kris discussed proposal #253: Indexing changes. This proposal removes  the Indexing domain, removing several elements, and moving some elements to base. This simplifies the indexing experience, simplifies shells, and removes unnecessary elements and domains. There are simple changes to grammar files and spec content. There are some migration implications. If implementations have used <index-base> and <index-sort-as>, they will have to change those. Any values for <index-see> will need to be modified. Any specializations will need to be changed. Any questions thoughts comments. Thanks to Deb and Robert for reviewing. I did find two instances where I had <indexterm-base> rather than <index-base>

Eliot: Is this an opportunity to improve the indexing to include a Primary term. Kris: what do you mean by Primary. Eliot: maybe primary is not the correct term. Of all the entries in the index, the primary points to the primary reference page for this term. This has not been in DITA from the beginning. Eliot. I have an index entry with 4 page reference. One of the pages is highlighted as the page that you might want to go to first. Kris: interesting. I think in classic indexing, this has been handled with See also. Usually there is not value in mentioning peripheral reference. Eliot: this is something that I've seen in documents that I've read. There currently is not something that is supported in DITA at this time. Kris: We have two options. We could certainly incorporate this into this proposal. But, I think the better option is to make this a new stage 1 proposal for new functionality. Rather than post to the list, can we just use this discussion as the initial Stage 1 proposal. Think about this and if anybody is interested in championing this. Eliot: DocBook does define an attribute value for normal or preferred to identify the preferred reference. Kris: that is helpful. Dawn: I wonder about reusability. Not sure if this is for us to decide, would the value apply for all reuse instances. Kris: Are there other comments? This will be on the agenda next week.

 

8. DITA 2.0 stage one proposals

We are holding on allow <example> in same locations as <div> until Scott Hudson returns from vacation.

 

Zoe introduced: Add an elements for things you press on keyboards. When I am talking about things I need to press on a keyboard. <userinput> is not quite right. This is different than a shortcut. Sometimes the key strokes are not a true shortcut. Dawn: In hardware this might be useful for other keys or button that you need to call out that a user interacts with. These are not UI controls, but a hardware thing to push or interact with. Kris: Clients have asked for a semantic element for hardware buttons. Eliot: the term that comes to mind is KeyCap. Kris: Are we thinking down the lines to have one element that applies to keyboard keys and hardware buttons, or are we talking about two elements. Alan: I think it would be nice to have one. Dawn: I was going down the path of one element, but I do think of clients who might have a need for both. But we could use @outputclass to distinguish. Kris: This is probably not something that we would necessarily put in the base. Zoe, were you thinking of putting this in base? Zoe: Initially, I was thinking software. Since I'm new, I'm not sure how you pick which domain. I'm not comfortable with button. Chris: I'm reminded of a term I saw once, CmdKey. Kris: Do we want to move this to stage 2? I think there will need to be lots of clarification on this proposal. Will there be two elements, will this be in the base or in a domain. Bill: I'm okay with moving this forward. Kris: Zoe, are you comfortable being the champion? Zoe: Yes, as long as I have a mentor to help me. Kris: Yes, this is part of why we have reviewers. Keith and Bill Burns volunteered to review. Kris volunteered to help.

 

9. New email on dita-comment

Robert: I think what they are asking for is text following a link to describe why a reader might visit that link. I think we have this already using the <desc> element. I've seen this in most places. Kris: I know you have another action item to answer Chris.

ACTION: Robert to answer Chris's emails

Alan: I'm reading the spec. Could be that the processor is not displaying the text.

Is this person staying in FrameMaker as the rendering engine? Kris: No clue.

 

10. Indexing inconsistency

Kris: This is something that I posted while looking at indexing in preparing to incorporate the new indexing proposal.

I came across some inconsistencies.

 

When an element contains multiple, direct-child, <sort-as> elements, the first direct-child <sort-as> element in document order takes precedence.

 

An implementation might give an error message, and might recover from this error condition by ignoring all but the last <index-sort-as>.

For sort-as we say take the first and for index-sort-as take the last. Either that was an oversight, or we didn't care.

 

Which direction do we go if we are removing <index-sort-as>? Do we change how processors handle multiple sort-as elements. I guess we need to choose one. Whichever way we go, we will break one or the other. Could be that there are few that have come across this issue as nobody has reported. How many processors are using sort-as? Eliot: I have some code for glossary using sort-as, but have not implemented that yet.

ACTION: Kris and Eliot, review and decide how to go forward. No action item after further discussion.

Eliot: I think going with sort-as rule since that was the first rule.

Robert: I'm conflicted on this. You can set two different index terms with different, conflicting sort-as values. This is a case where we say, processors decide which one is used.

Eliot: Or prefer the last if you can determine.

Robert: I'm not sure there is much point to define that here.

Kris: Particularly since we say that sorting is very implementation specific. In that case, we remove any reference to how a processor handles multiple sort as. Recognize that multiple sort-as is an error, but we don't provide any options for recovering from that error.

Eliot: I haven't thought about the use case that Robert brought up. You would have two entries in the glossary. Maybe, this case can only happen with index terms.

Kris: so you think the current text for sort-as is accurate.

Eliot: Yes, I think so.

Kris: I'm really going to want you as a stage 3 reviewer.

Eliot: Absolutely. I think we really need to think through the implications here. Or maybe we state if there are multiple sort-as, then it is processor dependent.

Kris: I think I know where we are now, I can move forward.

 

11. DITA 2.0 editorial work

Robert and I are working more slowly on our editorial work this month.

Robert: I don't expect that to change over the next week.

Kris: will be traveling next week.

 

12. Draft comments in latest working draft from TC attention

Kris: will move Item 12 to the beginning of the agenda for next call.

 

13. DITA for 'To be named' version 2.0

Kris: By default we are staying with DITA for Technical Content for lack of a better name.

We have several sub items to complete for this. We need a submodule in the DITA for Tech Comm

ACTION: Robert set up submodule

 

14. Stylesheets

We do have open stylesheet items. Cross references to footnotes are broken. Styling for related links is also broken.

ACTION: Robert to look at these. If you can pass the on if we have another volunteer.

 

Any comments, questions or announcements.

Dawn: I want to remind everybody about the call for presentations for DITA EU. I believe this ends in August.

 

11:58 ET Close

 

- Debra Bissantz

 

 

Deb Bissantz

Applications Engineer

Vasont Systems

A TransPerfect Company

221 W. Philadelphia St., Suite 114

York, PA  17401

 

t +1 717.793.3883

Skype: live:dbissantz

 

www.vasont.com

 



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