[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Question about DITA 1.2 item 12021
Thanks for clarifying. Given that, Paul's example would be changed to look like: <section> ... </section> <bodydiv> <section> <sectiondiv> <p>...</p> ... </sectiondiv> </section> <section> ... </section> </bodydiv> <section> ... </section> -----Original Message----- From: Robert D Anderson [mailto:robander@us.ibm.com] Sent: Wednesday, April 09, 2008 11:44 AM To: Earley, Jim Cc: dita@lists.oasis-open.org; Grosso, Paul Subject: RE: [dita] Question about DITA 1.2 item 12021 Just to be clear - the proposal as it was approved does not allow section to appear within sectiondiv (as shown in Paul's example). There are two elements. Bodydiv can group elements within a body (including the section element). Sectiondiv can group elements within a section (only the usual section content, no titles). Robert D Anderson IBM Authoring Tools Development Chief Architect, DITA Open Toolkit (507) 253-8787, T/L 553-8787 (Good Monday & Thursday) "Earley, Jim" <Jim.Earley@flatironssolutions.com> wrote on 04/09/2008 12:39:59 PM: > I guess I don't see the problem with your example. I can see valid > scenarios where grouped sections would be useful both for profiling > and conref'ed content. > > -----Original Message----- > From: Grosso, Paul [mailto:pgrosso@ptc.com] > Sent: Wednesday, April 09, 2008 11:33 AM > To: dita@lists.oasis-open.org > Subject: RE: [dita] Question about DITA 1.2 item 12021 > > OK, I may have been hasty. I'm still unclear on just what is being proposed. > > What I don't want to allow is something like: > > <section> > ... > </section> > <sectiondiv> > <section> > ... > </section> > </sectiondiv> > <section> > ... > </section> > > (with or without the final section) where what are presumably section > 1, 2, and 3 aren't siblings. > > paul > > > -----Original Message----- > > From: Robert D Anderson [mailto:robander@us.ibm.com] > > Sent: Wednesday, 2008 April 09 12:23 > > To: Grosso, Paul > > Cc: dita@lists.oasis-open.org > > Subject: RE: [dita] Question about DITA 1.2 item 12021 > > > > Hi Paul - > > > > > I would think we should allow either sections or sectiondivs, but > > > not a mix of both in any context. > > > > I think that is already the case. The sectiondiv element defines a > > block within section, and only goes within sections or within itself. > > My question about where to allow it is only about whether to allow > > it in the existing section specializations: > > refsyn, context, prereq, postreq, result, process > > > > Similarly, bodydiv defines a block within a body, and goes within > > body or within itself. My question about that in specializations is > > whether or how to allow it in conbody. Currently, Eliot's suggestion > > of conbodydiv (which sticks to the current conbody model) makes > > sense to me. > > > > > Given such broad issues, it makes me wonder if this proposal is > > > well enough baked to go into dita 1.2. > > > > I don't think these are very broad - the elements themselves have > > been pretty well thought out and defined, it's just the cascade down > > to specializations which needs to be made explicit. > > > > Robert D Anderson > > IBM Authoring Tools Development > > Chief Architect, DITA Open Toolkit > > (507) 253-8787, T/L 553-8787 (Good Monday & Thursday) > > > > "Grosso, Paul" <pgrosso@ptc.com> wrote on 04/09/2008 12:02:27 PM: > > > > > As mentioned further in this thread, I wouldn't want to be able to > > > have some sections in a bodydiv or sectiondiv and others not. It > > > would make it almost impossible to number such sections, for > > > example. > > > > > > I would think we should allow either sections or sectiondivs, but > > > not a mix of both in any context. > > > > > > Similarly with bodydiv. > > > > > > Given such broad issues, it makes me wonder if this proposal is > > > well enough baked to go into dita 1.2. > > > > > > paul > > > > > > > -----Original Message----- > > > > From: Eliot Kimber [mailto:ekimber@reallysi.com] > > > > Sent: Wednesday, 2008 April 09 11:08 > > > > To: Robert D Anderson > > > > Cc: dita@lists.oasis-open.org > > > > Subject: Re: [dita] Question about DITA 1.2 item 12021 > > > > > > > > Robert D Anderson wrote: > > > > > > > > > 2) The attributes for sectiondiv and bodydiv are not > > > > described. I plan to > > > > > use univ-atts and outputclass. > > > > > > > > That seems appropriate to me. > > > > > > > > > 3) Should bodydiv be added to the content model for conbody > > > > or refbody? If > > > > > added to conbody, should it be available only at the > > end, mixed with > > > > > sections and examples? Currently, sections and examples can > > > > only be used at > > > > > the end of conbody. I plan to leave bodydiv out of these > > > > models unless I > > > > > hear otherwise. > > > > > > > > I would certainly expect bodydiv to be available anywhere within > > > > body, not just where section is allowed, since it is not > > > > necessarily structural in the sense that section is, but may be > > > > used to simply group things for some purpose specific to a given > > > > author or > > specialization. > > > > > > > > > 4) Should sectiondiv be added to the content model of > > > > refsyn or the various > > > > > section specializations in task? That seems logical, but I > > > > have not added > > > > > it yet because I am not instructed to do so in the > > > > proposal. If it is added > > > > > to the "section.cnt" and "section.notitle.cnt" > > entities, which seems > > > > > correct, this will happen by default. That would also > > mean changing > > > > > <example> to use its own entity, rather than reusing > > section.cnt. > > > > > > > > Again, I would expect sectiondiv to be available within any > > > > specialization of section where it wasn't obviously > > > > inappropriate (because the section specialization was very > > > > highly > > specialized, for > > > > example). > > > > > > > > Cheers, > > > > > > > > Eliot > > > > > > > > -- > > > > Eliot Kimber > > > > Senior Solutions Architect > > > > "Bringing Strategy, Content, and Technology Together" > > > > Main: 610.631.6770 > > > > www.reallysi.com > > > > www.rsuitecms.com > > > > > > > > > > -------------------------------------------------------------------- > > - > > > > To unsubscribe from this mail list, you must leave the > > OASIS TC that > > > > generates this mail. You may a link to this group and all your > > > > TCs in OASIS > > > > at: > > > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr > > > > oups.php > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > - > > > To unsubscribe from this mail list, you must leave the OASIS TC > > > that generates this mail. You may a link to this group and all > > your TCs in > > OASIS > > > at: > > > > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.p > > hp > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]