OASIS Darwin Information Typing Architecture (DITA) TC

  • 1.  ITEM: Section div in LI

    Posted 06-02-2009 13:56 
    In thinking more about this more, I think my proposal, should I decide to
make one, would be to add


  • 2.  Re: [dita] ITEM: Section div in LI

    Posted 06-02-2009 14:41 

    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
    
mpriestl@ca.ibm.com
    
http://dita.xml.org/blog/25


    

    

    
Eliot Kimber <ekimber@reallysi.com>


    06/02/2009 09:56 AM

    		

    

    


    To
    
    		dita <dita@lists.oasis-open.org>

    


    cc
    
    		

    


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

    
Cheers,

    
Eliot


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


  • 3.  Re: [dita] ITEM: Section div in LI

    Posted 06-03-2009 11:55 
    On 6/2/09 9:40 AM, "Michael Priestley"


  • 4.  Re: [dita] ITEM: Section div in LI

    Posted 06-03-2009 12:38 

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


  • 5.  Re: [dita] ITEM: Section div in LI

    Posted 06-03-2009 13:38 
    On 6/3/09 7:37 AM, "Michael Priestley"


  • 6.  Re: [dita] ITEM: Section div in LI

    Posted 06-03-2009 15:44 
    This has been a useful analysis, Eliot and Michael. I think that at this
point, we need others of the TC to weigh in on Eliot's closing risk
assessment question,

> If it is the consensus that extending bodydiv to more contexts is too
risky,
>then I will leave it there for 1.2.

I expect that user representatives might find this to be a desired
enhancement with acceptable risk. I expect that vendors and implementers
may have some concerns about churn at this point. So I'm interested in
really understanding Eliot's assertion that textual constraints in the spec
are sufficient to guide users and implementers, in the absence of DTD/XSD
capability to fully enforce the constraint (if I understand the essential
dilemma correctly). This is a "guiding principle" moment that might come
back again and again on the way to DITA 2.0...

Regards,
--
Don Day
Chair, OASIS DITA Technical Committee
Architect, Lightweight DITA Publishing Solutions
Email: dond@us.ibm.com
11501 Burnet Rd. MS9033E015, Austin TX 78758
Phone: +1 512-244-2868 (home office)

"Where is the wisdom we have lost in knowledge?
 Where is the knowledge we have lost in information?"
   --T.S. Eliot


                                                                                                          
  From:       Eliot Kimber


  • 7.  Re: [dita] ITEM: Section div in LI

    Posted 06-03-2009 16:10 
    And just a clarification regarding my statement,

  "guiding principle" moment

The TC has already closed the scope for DITA 1.2, so I am not in favor of
opening that back up. I think the issue is understanding how we proceed
with similar scenarios as they pop up on the way to 2.0

Regards,
--
Don Day
Chair, OASIS DITA Technical Committee
Architect, Lightweight DITA Publishing Solutions
Email: dond@us.ibm.com
11501 Burnet Rd. MS9033E015, Austin TX 78758
Phone: +1 512-244-2868 (home office)

"Where is the wisdom we have lost in knowledge?
 Where is the knowledge we have lost in information?"
   --T.S. Eliot


                                                                                                          
  From:       Don Day/Austin/IBM@IBMUS                                                                    
                                                                                                          
  To:         Eliot Kimber


Related Content