Is the goal now a rearchitecture of
topic to create a common specialization structure for blocks, containers
of blocks, etc? With a shift from DTD-enforceable constraints to either
schema- or schematron-enforced ones?
If so, that puts it more in the realm
of 2.0 (which we've designated our soul-search and reconsider-assumptions
release) than 1.3.
Before we go any further - we are in
agreement that this kind of rework wouldn't go into 1.2 at this stage,
right?
Michael Priestley, Senior Technical
Staff Member (STSM)
Lead IBM DITA Architect
http://dita.xml.org/blog/25
Eliot Kimber <>
06/03/2009 07:54 AM
To
Michael Priestley/Toronto/IBM@IBMCA
cc
dita <>
Subject
Re: [dita] ITEM: Section div in LI
On 6/2/09 9:40 AM, "Michael Priestley" <>
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: <mailto:>
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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
