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: Nested subsections in specializations


I wanted to focus on what I perceive as a misunderstanding of our intent
in Erik's email:

> While I'm delighted and encouraged by the positive comments on 
> constraints, my thought is that contraints offer fine tuning for 
> a shared understanding of content expressed by the specialization.  
> The reason for the hesitation about the recursive <section> 
> element isn't because of structural issues but, instead, because 
> recursive sections seem to belong to a fundamentally different 
> model of content (divided narrative).

To be totally clear: I am not at all interested in arbitrarily nesting
section elements to create long narrative documents. Anyhow, I disagree
that there is any correspondance between narrativeness and nesting.
Novels tend not to nest much and yet are our canonical form of
narrative. Airplane manuals nest a lot and yet are seldom narrative (at
least they are not supposed to be).

In any case, I am interested in "template-like" specializations where
parts of the template are grouped. DITA itself uses this pattern:

task
    title
    prolog
        author
        source
        publisher
    taskbody
        prereq
        context
        steps
        result

DITA allows arbitrary nesting of things contained within sections but
not at the top level. IMHO, this is itself an arbitrary limitation. Why
don't we similarly limit lists within lists? If DITA were built on a
foundation that disallowed nesting then the structure would have to be:

task
	title
      author
      source
      publisher
	prepreq
	context
	steps
	result

If you understand why the prolog and taskbody make authoring and
processing easier then you understand my customers' goals as well. (in
fact, there is arguably a useful generalization of topic where "prolog"
and "taskbody" really are kinds of sections)

For example, We have a customer who has a more complicated and deeply
nested task structure (their prereq currently has subsections). If they
have even a single level beyond what DITA foresees then they must start
to divide things up into topics: not because they want to write long
narratives but rather because they want to take advantage of XML's
natural feature that allows them to group things in wrapper elements
(which DITA takes advantage of itself). I want people to define their
grouping element specializations and their topic segmentation levels
_based upon their content analysis_ and not in order to work around
arbitrary rules built into DITA.

 Paul Prescod


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