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: DiTA Tech Comm SC Minutes March 20, 2017


-------------------

 

OASIS DITA Technical Subcommittee meeting minutes 

Friday, March 20, 2017

Recorded by Jane Credland

 

 

Attendees:

 

Bob Thomas

Don Day

Joe Storbeck

Robert Anderson

Scott Hudson

Jane Credland

 

 

1. Approve minutes from December 12, 2016 and January 27, 2017

 

Moved by Bob, seconded by Joe. Approved without corrections.

 

 

——————

 

2. Diagnostic element stage 1 proposal

 

Bob doesn’t have the draft ready for this meeting.

 

AI – Bob – done by the next meeting in two weeks.

 

——————

 

3. Update on programming inline discussion

 

Scott was not able to get the proposal completed.

 

Nothing new came up at the Portland listening session, just confirmation of what was needed for the web services, but not any request for any particular element.

 

AI – Scott – proposal for next meeting in two weeks

 

——————

 

4. Separation of technical content from DITA 2.0 core

 

No plans to migrate the schema/technicalContent

 

Robert Anderson agrees with this. We can move away from the requirement for modular DTDs and XSLTs as part of the spec. Modularity will be part of the RNG.

 

Bob: Striking that paragraph from the draft.

 

Robert: Not sure that this is what he expected, just based on what he saw in the agenda. This seems to combine a lot of features into one. The separation of technical content into its own thing outside of the base. I think it’s going to be a lot more complicated than it sounds. It’s something that has to be considered on its own and it’s a big thing, and we need to work through implications, side effects and delivery issues.

 

Also covers the creation of a new information type, a new domain.

 

Bob: The information type is simply an example (a use case); it’s a hypothetical - it would be easier if it were like this. Needs to make that clearer.

 

Bob: not too many dependencies on the base spec.

 

Robert: something this doesn’t address - when shipping technical content as it’s own thing, do we also include the base as it’s own required work product, some part of it, or nothing (and we don’t include the cross-linking). They all have a different impact on usability.

 

Bob: is it our intention to quit shipping content models with the spec.

 

Robert: I’m hoping so.

 

Bob: need to solve the problem of attribute definition.

 

Robert: the linking tends to spider-web out from that. Topics about keys and conrefs. By the time you go through those attribute, most of those really complex attributes have a whole section in the architectural spec about them.

 

Bob: by the time you resolve the dependency chains, you have a base spec.

 

Robert: Do we bundle those things? Link to a published base spec? Easier if the base comes out first. Doesn’t have a good answer for this. Comes down to which answer we pick and what are the consequences.

 

Bob: one of the things I need to do is to talk about what those choices are.

 

Robert: do we want to come out of this group with a recommendation? Something that the TC as a whole will have strong opinions about.

 

Bob: we can recommend something but…

 

Robert: might be good to list those issues and get feedback from the TC.

 

Bob: best tack is to the list the possibilities and ask the TC for guidance. No requirement that you go to the TC with a complete, ready to approve, proposal

 

Jane: question about backwards compatibility.

 

Robert: separating out as a package shouldn’t have any impact on its own. Almost what we have today except that we approve three packages at once, rather than independently.

 

Bob: we may do things to the spec that impact backwards compatibility, but this won’t. Owe it to our users to have a very solid reason fro doing it.

 

AI – None taken

 

——————

5. Bookmap and DITA inadequacies (TC discussion)

 

Bob: there is a need for some kind of publication style construct, beyond what is available in out of the box maps. Also discussed missing bookmap definiciences. Missing some metadata functionality. Some discussion about he content model being overly restrictive. Where do you put things like key definitions (resource only links to keydefs)? Where do you put information about your cover page (info on the cover beyond what’s in the metadata, graphic, etc).

 

In 2.0 timeframe, probably need a more generic publication construct. Might be things that can be done to maps to make them more useful, reducing compatibility problems.

 

Scott: one of the things that maybe we can borrow from DocBook - they have a cover element, where you can specify a cover image and other specific items that might be a useful way to get around the lack of a specific element for that in the book structure.

 

Bob: is there an interest in the SC to take a look at bookmap to see what we can do to improve it.

 

Scott: I’m definitely interested in that.

 

Don: I’ve been pondering just how high up the design ladder one might need to climb; there’s a higher echelon of job control that includes not only the content decision in ditaval files but also the cover and other items we’ve put into the book metadata but which might be better controlled at the

 

Don’t want to propose it at the moment; not just book production but job control issues. May include things like digital asset management.

 

Bob: one of the things I would like to see is a bookmap or something that succeeds it in the core specification.

 

Robert: set out a group mind map space somewhere

 

Jane; need to provide a way to make it not user-editable always.

 

Bob: that’s an implementation issue, in the DITA-OT for example

 

Robert: thinks Bob is right. The TC is to provide mark-up. What can be edited or not edited is part of implementation; IA can provide specializations o remove that element. IBM is already doing that. Alternatively, we can  - schematron in Oxygen - add a rule in your editor to flag it; can do the sam thing in your transforms TC can’t provide an element and then say here’s a way to remove it

 

Bob: Before we can go much further, it would be good to see what the TC wants to do about creating a new specialization.

 

Robert: it hasn’t progressed to the point where anyone has taken ownership of it but the discussion seems to generally be in favor of it.

 

Bob: either way, we probably need to be doing something with bookmap in 2.0. My guess is that we’re not going to eliminate or even deprecate bookmap in 2.0.

 

Scott: I think it will be additions, if anything.

 

Bob: wants to try and do this without introducing a lot of additional complexities to the bookmap structure - we have some opportunities to make it easier to use without making it more complicated.

 

Scott: if we can address some of the common needs, not trying to over-ride something to get support for certain things; it will be a lot more helpful for folks

 

Bob: if we take this on, I’d like to get feedback from the DITA-OT project on what they’d like to do

 

AI – None taken

 

——————

 

6. Additional items

 

Scott: Glossary is a major painpoint for most people.

 

Bob: on the agenda for next time. I would like to see where the TC is going with glossary before we invest a lot of energy into it

 

Scott: volunteered to try to put together a proposal for the TC. He’d be fine with including it here to get some early feedback

 


--
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]