OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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