[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] ITEM: Section div in LI
On 6/2/09 9:40 AM, "Michael Priestley" <mpriestl@ca.ibm.com> wrote: > 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). We wouldn't be making <p> nestable (because <p>'s content does not allow %basic.block;), but your point is still valid: it would, indirectly, allow an <lq> to have an (indirectly) nested <lq> with no intervening block-context-establishing element, such as <ul> or <fig> (because <sectiondiv> must necessarily allow <lq> [and fig, and table, etc.). However, I think that trying to solve this problem at the DTD level is simply not sustainable and not in the best service of DITA users. The general need for a *single* specialization base to enable the creation of arbitrary (untitled) containers is inherently at odds with the desire to disallow, at the most general level, apparently inappropriate nesting, such as <lq> with a descendant of <lq>. But that's an unavoidable aspect of a standard that is necessarily as general as DITA is. It also runs into the fact that DTDs (and schemas) alone are inherently insufficient to express all possible useful constraints. There comes a time where you just stop trying. It is, ultimately, sufficient for the *prose* of the DITA spec to say "structures that allow nesting of <lq> within <lq> without an intervening block context establishing element (e.g., lists, figures, long quotes, or tables) is not allowed". The fact that you can't express this constraint declaratively in DTD or XSD syntax (but you almost could in SGML DTD syntax and might be able to in RNG and definitely can using Schematron) is really irrelevant--the DTDs are at most a convenience, but we cannot depend on them as the primary definition of what is or isn't allowed (even though that is how DITA has been largely defined to date). So I agree that the standard should disallow direct nesting of <lq> within <lq> [Actually I don't--I think that's a bug too because I can immediately imagine having a long quote that is itself a quote of text that includes another quote--I can't think of any absolute semantic reason to disallow nested long quotes, now that I think about it.] but I disagree that the mechanism for stating that rule is the DTD declarations--it should be the prose of the specification, at least in the case where DTD syntax alone is insufficient to express the constraint. There are already a number of such statements in the DITA spec--It's hard to see how one more or less would make much difference. > 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. That wouldn't satisfy the requirement, which is to be able to have a *single* specialized element type that is allowed in all the places I would expect to be able to have blocks. This would require me to have a bunch of distinct specialized element types with exactly the same semantic when otherwise a single specialized type would suffice. The fact that there is already a difference between <sectiondiv> and <bodydiv> is a problem, which is why it think it probably makes sense to allow <sectiondiv> directly within body--without that I must have two different variants of the same specialization, even if I have no need to allow sections within my *div specializations, just so I can have the same structure allowed within body and within sections. That seems like a bug to me. If I wanted to take this to the extreme I could argue that really there should only be one <*div> element and the spec can simply state that divs within sections cannot contain divs, but that particular constraint is important enough and it would be hard enough to implement that constraint in specializations, that it probably does make sense to have the sectiondiv/bodydiv distiction. But I can't see that the same argument applies for e.g. <lq> or <fig>, where it's not about misusing <section> to create titled hierarchy, but about avoiding (arguably) nonsensical combinations of descendants. That is, the DITA spec has drawn a particularly hard line on the non-nesting of sections, for reasons of principle that are central to the basic DITA design philosophy (title hierarchy is the exclusive domain of topics and maps). That same principle does not, as far as I can see, apply to elements within topic bodies. Cheers, E. ---- 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]