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.
Decision:
(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.
============