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


On 6/3/09 7:37 AM, "Michael Priestley" <mpriestl@ca.ibm.com> wrote:

> 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?

No, the goal is to provide a single specialization base for non-titled
arbitrary containers of blocks. I don't see that as "rearchitecting topic"
since it doesn't change the essential nature of topics or even of blocks.

I might concede that adding such a specialization base *accelerates* the
*existing* shift from DTD-enforceable constraints, but it does not *start*
it--that aspect of DITA has always been there and is an unavoidable aspect
of any standard as general as DITA is, and especially as general as the
specialization feature requires, at the most general level.

That is--DITA has *always* had some constraints that cannot be DTD-enforced,
although it clearly sought to avoid them as much as possible (for good
reason). 

It's always been my opinion that with DITA 1.2 we have reached the point
where it is impossible or impractical to satisfy all requirements in ways
that can be constrained with DTD-based mechanisms alone. That is, we have
*no choice* but to put greater emphasis on the prose of the spec to define
constraints--I made that argument a long time ago in the context of the 1.2
effort.

In the specific case of <bodydiv>, I'm making the observation that the
feature, as currently specified, is of *limited utility* because of where
bodydiv is not allowed. I am also observing that it *does not meet the
requirements of my _current clients_*.

Thus I raise the issue.

I appreciate the desire for conservatism in making revisions to the spec,
which is one reason I'm not making a proposal at this time, only raising an
issue.

At the same time, DITA exists to serve its users and we have to weigh the
value of the standard to its current and potential users against the risk of
unintended consequences. On the other hand, it should be clear to all
observers that designs that comprise DITA 1.2 have not, by and large, been
fully tested in anything like a practical context. Thinking about a given
proposal can only take you so far, although I certainly should have realized
the problem with the bodydiv/sectiondiv proposal much sooner than now (but
better now than even later.

Thus it should be no surprise that we are finding places where the original
design isn't quite right.

> 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.

I do agree that a deeper re-architecting of the DITA architecture must wait
until 2.0--but I don't think I'm suggesting that level of change.

But I will also say that I have, over the years, decided that, by and large,
any form of declarative constraint specification is, at best, a convenience,
that what is important is the rules as defined for and understood by humans.
That definitely colors my weighting of these sorts of issues: stated simply,
the fact that the base element type DTDs might allow <lq> within <lq>
doesn't bother me *at all*.

But that's my bias.

> Before we go any further - we are in agreement that this kind of rework
> wouldn't go into 1.2 at this stage, right?

No, we are not in agreement--barring deeper analysis, which I can certainly
do--I have strong motivation to make <bodydiv> more useful *right now*, not
in 1.3. If it is demonstrated that this change would entail a lot of
potentially dangerous uncertainty, then I would agree, but it's hard to see
how that could be given the generally benign nature of topic body content.
It's already hard to process completely and sensibly given all the
already-allowed combinations (e.g., mixed content and paras within <lq> or
<li> or <body> or <section>). So it's hard to see that allowing bodydiv more
places changes the essential nature of that processing. But perhaps I'm not
looking at the right processing aspects?

DITA has, for the most part, been very carefully designed to impose just
enough constraints to enable smooth interchange and interoperation and
believe me I appreciate perhaps more than anyone other than Michael--it is
the essential distinguishing magic of DITA.

But DITA also has to provide a lack of constraint in a lot of places, even
where a concrete design would naturally impose those constraints.

This issue one that sits on the boundary between essential constraints and
essential non-constraints.

If it is the consensus that extending bodydiv to more contexts is too risky,
then I will leave it there for 1.2.
 
> 
> 
> Michael Priestley, Senior Technical Staff Member (STSM)
> Lead IBM DITA Architect
> mpriestl@ca.ibm.com
> http://dita.xml.org/blog/25
> 
> 
> 
> Eliot Kimber <ekimber@reallysi.com>
> 06/03/2009 07:54 AM
> 
> To
> Michael Priestley/Toronto/IBM@IBMCA
> cc
> dita <dita@lists.oasis-open.org>
> 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>
> 
> 
> ---------------------------------------------------------------------
> 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
> 
> 

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