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: Minutes from the January 27, 2017 Tech Comm Subcommittee meeting

Thank you, Jane for doing this. The minutes are as follows:

1. Discussion: Troubleshooting model


Silke Achterfeld - discussed her comments on troubleshooting model - no place for diagnosis.


Scott Hudson: Listening session - Amazon - People found it a bit too constricting for what they’re needing to do. Need to review notes for details. He has a contact if we need more details.


Looking for FAQ style or simple Q&A types of information; same remedy might apply to multiple causes - need to be able to separate the Q & A or the diagnosis and remedy.


Jane - separate topics for the different pieces - chunk together in a map


Bob: Send out a request for requirements during the 2.0 timeframe; caveat that we don’t break backward compatibility to the existing model


Robert A - two aspects - one was troubleshooting and the other was a step-by-styes diagnostic type; (IBM). Is that’s what’s being mentioned here


Agreement from the group on this.


Troubleshooting and Troubleshooter - Troubleshooter has more in common with the learning model.


Bob - call it diagnostic procedures


Bob - in general we need to look at anything that’s required [in the current model] and see if we need it.




(a) Troubleshooting model updates are an item for ongoing work in the 2.0 timeframe - need to turn it into a feature proposal for 2.0


(b) Templates for feature proposal  must include backwards compatibility; bar must be set very high if you need to break it.




2. Discussion: Optimizing Content Model for Authoring


Bob - Complications around constraints. Need to give the DITA TC time to hammer it out before we move further on it. Would like constraints to play out a little bit before we get too involved.


Robert - primarily focused on the technical implementation. He wants to simplify that part. Regardless of that, this group is free to focus on what the ideal authoring constraints are. Howe we get there is a totally separate thing (DITA DTDs)


Scott - for 2.0, need to make it more modular so that folks can make it much more easy to include the ones that they need. Need to take a look at what would be a core authoring set for the techcomm element.


Bob - what’s preferred and what’s essential.


Robert - we can help divide them up into logical groups - helpful input to the TC effort. If you’re in an authoring context, is it a best practice or do we need to enforce it? What’s the ideal and how do we get there.


Bob - the ideal would be a close fit for 90% of the people


Jane - we need to validate whatever we come up with the user community.


Scott - need to go through the listening session notes and try to identify the feedback from the user community about what’s missing and what they like (from the perspective of the techcomm elements). We have contact information for the listening session folks and can ping them in addition to making it known on the rita-users list or other forums.


Robert - there’s no one best practice for all folks; in the end, different sets of user needs separate things


Bob - need to preserve the structural compatibility - allow people to revert to the unconstrained version


Scott - people by adopting 2.0 acknowledge that there may be some migration effort; need to validate against the full complete version so it doesn’t break people’s content.


Bob - in a lot of ways, a set of best practices ,rather than an underlying specification


Don - DTD subsetting - with the intent to take any such standard and pass it through DITA publishing - can’t be expressed as a design pattern for doing specialization. Need to have some discussion about whether constraints can be done as something more simple such as subsetting rather than specializing and constraints


Bob - used subsetting at Avaya to get rid of the mixed content


Don - for editors who are available to provide customization of selectable elements - providing nearly the same thing; reducing the number of elements that are possible and the context in which they appear


Bob - thinking about coming up with authoring environments or profiles for different use cases


Don - benefit is that it gives folks who can customize pulldown options the ability to agree on the limited choices to be available


Robert - outside of the spec but within the realm of this SC - could publish a committee note or something “hey you might find this useful”


Bob - what’s next is to come up with a formal or a living document to describe a better environment for authoring - put that into a working proposal


Scott - OASIS JIRA or FAQ are options


Bob - put it on the wiki might work, but initially just distribute it on the list


Decision: Nothing decided today




3. Discussion: Software/Programming Inlines


Scott - feedback from listening sessions is around software/programming inlines. He’s going to try to pull together a proposal for the group as regards to some items that we need to include per requirements


The existing inlines don’t handle or easily describe web services documentation. Are there some more specific inlines that can be added to make it easier to do that kind of sw documentation


Decision:  Scott will put together a proposal but would appreciate any additional feedback or items.



Bob Thomas
+1 720 201 8260
Skype: bob.thomas.colorado
Instant messaging: Gmail chat (bob.thomas@tagsmiths.com) or Skype
Time zone: Mountain (GMT-7)

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