Hello, I just have a little comment on 8.Publishing Subcommittee report ... Scott suggests everyone read it and provide comments.
With an external view (no knowledge of publishing) I wondered what is the real motivation to have 3 distinct elements (dialogue, drama, poetry) because they seem to have the same goal "speeches" and also have the same xml definition in the spec ( http://docs.oasis-open.org/docbook/specs/publishers-1.0-spec-cd-01.pdf) If the definition is the same, isn't the role attribute sufficient within a single dialogue element? Or is it a choice made to simplify the stylesheet work as these elements really need a different printing layout? Best regards, Cédric, On Wed, Jul 15, 2009 at 9:37 PM, Bob Stayton <[email protected]> wrote: > DocBook Technical Committee Meeting Minutes: 15 July 2009 > ============================================================= > > The DocBook Technical Committee met on Wednesday, 15 July 2009 at > 01:00p EDT (10:00a PDT, 17:00GMT, 18:00BST, 19:00CEST, 02:00JST+, > 022:30p India+) for 85 minutes. > > 1. Roll call > > Present: Paul Grosso, Gershon Joseph, Scott Hudson, Dick > Hamilton, Nancy Harrison, Larry Rowland, Bob Stayton, > Norm Walsh. > > Absent: Jim Earley, Keith Falhgren, Patricia Gee, Jirka Kosek, Corey > Leong, Dave Pawson, John Pederson, Pine Zhang > > 2. Accepted the minutes [1] of the previous meeting. > > 3. Next meeting: 19 August 2009 > > No regrets so far. > > 4. Review of the agenda. > > Add new RFE 2820947 "Ability to transclude text" as 9b. > > 5. Review of open action items > > a. Bob to organize TDG reading after names are fixed. > REMOVE (see agenda item 7) > > b. Jirka to add schema comparison table to DocBook 5.0 Transition Guide. > COMPLETED > > c. Norm to work with Mary to make Publishing Subcommittee > schema a Committee Working Draft. > COMPLETED > > d. Norm to work with Keith and Scott to update the OASIS committee > site to make the Publishing Subcommittee Working Draft > publicly available. > CONTINUE > > e. Norm to put the new backwards compatibility policy in the spec. > CONTINUE > > f. Norm to put the new backwards compatibility policy in the > reference documentation. > CONTINUE > > g. Norm will update 5.1 with changes to initializer > content model. > COMPLETED > > h. Norm to take a look at the inlines and make a proposal > regarding RFE 2791288. > CONTINUE > > 6. DocBook 5.0 standards update. > > Norm is working with Mary to submit DocBook 5.0 as an > OASIS Standard. It should be ready to go by the > end of this week. > > 7. New edition of DocBook: The Definitive Guide > Dick and Norm announced that O'Reilly will be publishing > a new edition of DocBook: The Definitive Guide. > Norm suggests that the committee review the > reference pages when they are ready. He hopes to > have them ready by 1 September. > > 8. Publishing Subcommittee report. > > "The DocBook Publishers Schema Version 1.0" Committee Draft > specification [2] is available for review. The review > period will end 31 August. Scott suggests everyone read > it and provide comments. > > 9. Using a map for modular DocBook. > > Discussion of Larry's second sample of DocBook assembly. > > Norm raised concerns about the renderas attribute as well > as importing foreign content such as DITA or other schemas. > That implies some transformation process, and will the > committee specify that? > > Gershon: DITA uses specializations of topicref > in the bookmap schema to indicate how a topic is to be > represented. He also pointed out that in DITA maps, > topicref can only refer to a topic element. > In DocBook assembly, any DocBook element can be included, and the renderas > attribute allows the > author to indicate how it would be represented. > > Larry: for foreign content, perhaps have a section in > the assembly that identifies a stylesheet to be used > for transforming content during the assembly. > > Bob: we should separate including DocBook content (easy) > from including foreign content (harder). > > Norm: transformations are defined by the implementation. > We may provide some reference implementations. > > Larry: assembling a help system requires different > processing from assembling a book. > > Norm: put an "outputtype" attribute on the structure element > as a whole to indicate how it should be processed overall, > and use renderas at the element level to map one element > to another. > > Bob: One assembly mode is to map all referenced elements > into a valid DocBook book, so nested topics would > become sections, for example. Another assembly mode > creates a structured TOC and processes each reference > separately (similar to the DocBook Website customization), > without assembling it into a book first. > Larry: may use an attribute on elements to indicate > chunking level. > > ACTION: Larry to create a new assembly example for next meeting. > > 9b. RFE 2820947 "Ability to transclude text". > > First we discussed conref since the requestor mentioned it. > Gershon and Paul described problems with implementing > conref, including hard coding references. Gershon suggested > that DITA's keyref, which uses a level of indirection, > would be more flexible. A note from Eliot Kimber > didn't reach the list in time, so it will be reviewed > for the next meeting. > > Paul: use existing standards such as XInclude with xpointer. > Creating new schemes is a whole big thing. > > Bob: the xpointer scheme is not a standard, so there is no way > to include all the children of an element without including > the element itself. That can help with the problem of duplicate > ids when importing the same content more than once. > > Paul: If the children that are imported have IDs, then > the duplicate ID problem remains. > > Norm: perhaps we could define some small subset of > xpointer scheme. > > We will continue this item next month, referring to it > as "transclusion" rather than "conref". > > > 10. Add topic element (RFE #2820190). > > Bob described his proposal for a new topic element. > Norm said the need for a specific element for > standalone topics still exists, and this proposal meets the need. Larry > thought allowing some > elements to serve as containers of a sequence of > topics was a good idea. > ACTION: Norm to create a DocBook 5 customization layer > with topic, so we can experiment. > > ACTION: Bob to present the proposal to the docbook > mailing list when Norm has the customization done. > > > 11. Review of Requests for Enhancement > > To browse a specific RFE, enter the URL (on one line): > > http://sourceforge.net/tracker/index.php?func=detail&;; > group_id=21935&atid=384107&aid=XXXX > > RFEs to revisit for 6.0 > 1907003 biblioid content model too broad > RFEs to be considered 1679665 Add better support for modular > documentation > Discussed as item 9. > > 2770858 Add limited emphasis to ubiquitous inlines 2791288 add > quote to corpauthor and gui elements > Awaiting Norm's action item. > > 2820190 add a topic element > Discussed as item 10. > > Meeting adjourned at 2:25pm EDT. > ----- > > [1] http://lists.oasis-open.org/archives/docbook-tc/200905/msg00009.html > [2] http://docs.oasis-open.org/docbook/specs/publishers-1.0-spec-cd-01.pdf > > Bob Stayton > Sagehill Enterprises > [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
