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] ITEM: Section div in LI

I'd be concerned about this for 1.2 because we don't have the time to think through all the implications. I'd suggest it as a change to consider for 1.3, where we can spend more time on the design.

As one immediate concern - currently block content is at least somewhat resistant to nesting because the content models explicitly exclude it. For example, the content model of p does not include p, lq does not include lq, fig does not include fig, etc. If we make sectiondiv available in all of those contexts, we will be making p able to nest almost directly (the intervening sectiondiv having no processing implications).

An alternative would be to create a sectiondiv-equivalent for each of the block content model variants currently in the DTD. That would mean adding half a dozen new elements though, rather than just making the one ubiquitious. Which again reinforces the need to defer this to 1.3 for consideration.

Michael Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect

Eliot Kimber <ekimber@reallysi.com>

06/02/2009 09:56 AM

dita <dita@lists.oasis-open.org>
[dita] ITEM: Section div in LI

In thinking more about this more, I think my proposal, should I decide to
make one, would be to add <sectiondiv> to both <body> and %basic.block; (and
all the %basic.block.* entities).

This would allow specializations of <sectiondiv> to go anywhere all other
blocks are allowed, but because <sectiondiv> does not allow <section>, would
not have the side effect of allowing sections to (indirectly) nest.

Without this change, the value of <sectiondiv> as a means to create
general-purpose and arbitrary containing structures is severely limited,
making it almost useless for a number of important use cases, in particular,
creating an element that authors would expect by its nature to be allowed
anywhere other blocks (e.g., <p>) are allowed.

I will be unable to attend today's meeting but I wanted to provide some
concrete analysis to my initial request for discussion.



Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
email:  ekimber@reallysi.com <mailto:ekimber@reallysi.com>
office: 610.631.6770 | cell: 512.554.9368
2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403
www.reallysi.com <http://www.reallysi.com>  | http://blog.reallysi.com
<http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]