RE: [dita] Proposal for Consideration: Default Behavior for List Items

["Bruce Nevin (bnevin)" <bnevin@cisco.com>]

I have withdrawn my objection as being impractical to apply to DITA, on
the backward-compatibility grounds that Michael raised. To these you,
Eliot, have added (1) architectural grounds and (2) application scope
grounds. 

Andrzej identified inadvertent consequences for translation that call
for careful reconsideration. IMO this requires a much deeper semantic
analysis for restricted domains, as in http://mlp-xml.sourceforge.net/.

The following two comments are a bit off topic. If the second one merits
further discussion it might belong in a different thread.

I would cavil about Elliot's point (2) that there are concerns of
content developers that are pretty universal, which should be
distinguished from those specific to technical documentation. The point
is academic in the current context, given the above, but may apply
elsewhere. Anyway, I would guess that a great many of such concerns
raised from the tech docs world fail adequately to distinguish
structure/semantics from rendering/presentation.

Point (1) below underscores a confusion that may be prevalent in the
user base. It seems to me that it is common for vendors and consultants
to promote the use of vanilla DITA and to counsel their customers to
minimize specialization. Yes, users should proceed cautiously and
circumspectly with specialization, but if they think that it is a DITA
best practice to use only the base content models they are badly
misunderstanding that guidance. Certainly, minimizing specialization
simplifies implementation, customization, and support; possibly some
vendors or consultants do not adequately communicate the point; possibly
some do not fully embrace it. 

	/BN

> -----Original Message-----
> From: Eliot Kimber [mailto:ekimber@reallysi.com] 
> Sent: Tuesday, June 17, 2008 10:54 AM
> To: Bruce Nevin (bnevin); Erik Hennum
> Cc: Andrzej Zydron; dita; Michael Priestley
> Subject: Re: [dita] Proposal for Consideration: Default 
> Behavior for List Items
> 
> I'd like to point out a few things that make any arguments 
> around the markup design essentially moot:
> 
> 1. The base DITA content models are *NOT* authoring models 
> and cannot be.
> They are the models needed to enable an appropriate range of 
> specializations and/or local markup practices. That means 
> that, for example, list items
> *must* allow both PCDATA content and block elements. As has 
> been pointed out, that doesn't mean that all users of DITA 
> have to allow them, but the standard as published has to allow it.
> 
> NOTE: There are many places in the current DITA design where 
> it is over constrained. Some of these have been addressed in 
> 1.2, some cannot be corrected until 2.0.
> 
> 2. DITA is not just for technical documentation, so arguments 
> along the lines of "this is not good technical documentation 
> practice" or "technical documents don't need it" are out of 
> order and should be avoided in any discussion of base DITA 
> content models. In the context of a techdoc-specific 
> specializations, they are perfectly fine. But base DITA 
> (e.g., topic and the core modules) are not technical 
> documentation specific.
> 
> 3. Backward compatibility requirements in 1.x mean that even 
> if we thought the content model should be more constrained, 
> it can't be.
> 
> Jeff O. correctly expressed my original concern, namely, 
> should the spec be clear on what the *default* presentation 
> expectation is for list items with and without initial block 
> containers. We still need to answer that question.
> I submitted proposed language and am waiting for the 
> opportunity to move that we vote on it.
> 
> 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.  You may a link to this group 
> and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
oups.php 
> 
>