[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook] DocBook Technical Committee Meeting Minutes: 21 October2009
Hi all, thanks for those reports, it's good to see DocBook is moving and headed by an awesome team. I had a question about the DocBook to SCORM package mentioned in the minutes: is this what you had in mind? http://pyxx.org/convert-docbook-to-scorm/ Thanks, Camille. Norman Walsh wrote: >> DocBook Technical Committee Meeting Agenda: 21 October 2009 >> ============================================================= >> >> The DocBook Technical Committee met on Wednesday, 21 October 2009 >> >> The DocBook TC uses the #docbook IRC channel on >> irc.freenode.org. The IRC channel is used for exchanging >> URIs, providing out-of-band comments, and other aspects >> of the teleconference, so please join us there if at >> all possible. >> >> Agenda >> >> 1. Roll call >> > > Present: Scott, Larry, Jirka, Corey, Norm, Bob > > Scribe: Norm > > >> 2. Accepting the minutes [1] of the previous meeting. >> > > Accepted. > > >> 3. Next meeting: 18 November 2009 >> > > No regrets heard. > > >> 4. Review of the agenda. >> > > Scott: Please add the request to form an eLearning TC > > For next month: > > Dealing with corss references in modular documentation, see > http://lists.oasis-open.org/archives/docbook-tc/200910/msg00006.html > > >> 5. Review of open action items >> >> a. Norm to put the new backwards compatibility policy in the spec. >> >> b. Norm to put the new backwards compatibility policy in the >> reference documentation. >> >> c. Norm to take a look at the inlines and make a proposal >> regarding RFE 2791288. >> >> d. Norm to reply to RFE 2820947 (transclusion) with the >> committee's concerns (see the minutes). >> > > Continued: a-d > > >> e. Bob to develop a stylesheet to transform an assembly >> into a document. >> > > Completed. > > >> f. Larry to revise the assembly sample and schema based on comments. >> > > Completed. > > >> g. Gershon to develop a reltable example. >> > > Continued. > > >> 6. DocBook 5.0 standards update. >> > > We're within 12 of having all the votes we need! > > Everyone look through the list and find people you know. Send them > private encouragement to vote ("Yes" of course :-) and then send the > list of contacts to the docbook-tc list so we can minimize overlap. > > >> 7. New edition of DocBook: The Definitive Guide >> > > Not a lot of progress. January looks more likely than December, but > we're still working on it. > > >> 8. Publishing Subcommittee report. >> > > Scott: We went through final review comments period. What came out > that we need to add documentation in the schema and create a DTD > version. The SC has decided to make those changes, after which time > it'll require another 15 day review period. > > Scott The comments are in the schema, but I can't create a DTD using > the tools. > > Norm: Yeah, the tools for that are pretty awful. > > Some discussion. Scott will try to use the XSLT simplification tools > that are part of the main distribution process. > > >> 8b. Create an eLearning TC >> > > See: http://lists.oasis-open.org/archives/docbook-tc/200910/msg00017.html > > Scott summarizes. With assembly and topics coming, DocBook is an even > better fit for the eLearning/training paradigm. > > A DocBook to SCORM conversion utility has already been developed in > the community. > > Larry: I think this is a good idea. The changes we're making for > modular DocBook make this an ideal time to embark on this effort. > > Scott: One comment that I received was that this might compete with > the DITA eLearning specialization. But I think that's OK, DITA isn't > the only game in town. > > Proposal: The DocBook TC endorses the formation of an eLearning > subcommittee under the charter proposed by Scott. > > Accepted with no objections. > > >> 9. Modular DocBook. >> > > Larry: I've been responding to comments from people. I've added a > default output format to the structure element that would apply to its > children. I won't repeat everything that we discussed at the last > telcon. > > Larry: When I added the default output format to structure, I needed > some way to say "don't render this" and I may have overloaded > renderas. On line 259 of the file, I have an output statement with two > output formats and a renderas of "norender". > > [[ Some discussion of the example in the assembly file. ]] > > Some sentiment that using renderas="norender" is abuse of the renderas > attribute and should be changed. > > Although not rendering in some formats is a kind of filtering, it > seems not to be one of the normal effectivity attribute so filtering > doesn't apply? Not complete agreement. > > Norm ponders the use of more complex XPath evaluation to simplify > authoring. > > Consensus seems to come back to adding a new attribute to the output > element that indicates that the content should be suppressed. > > Possible names: omitoutput, discard, suppress > > Straw poll, vote for up to two: > > omitoutput : > discard : 2 > suppress : 3 > > Is there anyone who cannot live with "suppress"? > > Proposal: Add a suppress attribute to output, if suppress=true (or 1) then > the output is not rendered. > > Accepted. > > (In addition, Norm suggests removing "output" from the attribute names > on the <output> element.) > > Additional discussion about the use of grammer= on line 317. Conclusion: > change grammer= on that line to transform= and add it to the transforms > section at the bottom (renamed from grammartransforms): > > <module resourceref="help.tutorial"> > <output outputformat="helpsystem" outputfile="xidi-help.tutorial" > grammar="tutorial"/> > ... > </module> > ... > <grammartransforms xml:base="file:///opt/xidi/util/grammartransforms"> > <transform grammar="dita" fileref="dita2docbook.xsl"/> > <transform grammar="tutorial" fileref="docbook2tutorial.xsl"/> > </grammartransforms> > > Becomes: > > <module resourceref="help.tutorial"> > <output outputformat="helpsystem" outputfile="xidi-help.tutorial" > name="tutorial"/> > ... > </module> > ... > <transforms xml:base="file:///opt/xidi/util/transforms"> > <transform grammar="dita" fileref="dita2docbook.xsl"/> > <transform name="tutorial" fileref="docbook2tutorial.xsl"/> > </transforms> > > Bob encourages everyone to try out the transform stylesheet that he > supplied which generates an assembly file for an existing document. > > Jirka suggests that perhaps the assembly elements should be in a > different namespace. > > Norm agrees that its worth considering but worries about the fact that > authors would have to switch back and forth between the assembly > namespace and the docbook namespace for content. > > Bob wonders if this is really necessary? It would definitely > complicate things. > > Jirka isn't sure, just thinks it's worth considering. > > Larry raises questions about how much simplicity and defaulting should > be allowed. We want to make sure that we're optimizing for what we're > trying to do. Short term optimization may not be valuable in the long > run. > > >> 10. Add topic element (RFE #2820190). >> > > We have a design, but we're leaving this open until we're a little > farther along. > > >> 11. Review of Requests for Enhancement >> > > Postponed until next meetings. > > >> [1] http://lists.oasis-open.org/archives/docbook-tc/200909/msg00005.html >> > > 12. Any other business? > > None heard. Adjourned. > > Be seeing you, > norm > >
begin:vcard fn:Camille Begnis n:Begnis;Camille org:NeoDoc adr:;;5 rue de la Touloubre;Venelles;;13770;France email;internet:camille@neodoc.biz tel;work:+33.9.54.96.99.55 tel;fax:+33.9.59.96.99.55 tel;cell:+33.6.33.15.10.23 url:http://www.neodoc.biz version:2.1 end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]