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] Need Clarification on Implications of Different List Markup Patterns


Hi Erik,

 

Yes, this is an interesting way to provide further restrictions on a “loose” content model without the need to make it a specialized semantic type – which does fit the kind of situations I’m thinking of.

 

What I am also suggesting, however, is that the base DITA topic and core specializations be explicitly made looser, with a specialization or constraint mechanism then used to specify recommended best practice usage.

 

For example, the base DITA topic could be changed to allow nested sections, which would make it much more extensible.  But for technical writing the committee could also specify constraints that do NOT allow nested sections as a recommended best practice.  Today, these recommended best practices are built right into the base topic model.

 

Thanks much,

Eric

 

Eric Severson
Eric.Severson@FlatironsSolutions.com
303-542-2125

Flatirons Solutions Corporation


From: Erik Hennum [mailto:ehennum@us.ibm.com]
Sent: Tuesday, February 12, 2008 9:23 PM
To: Severson, Eric
Cc: dita@lists.oasis-open.org; ekimber@reallysi.com; gershon@tech-tav.com
Subject: RE: [dita] Need Clarification on Implications of Different List Markup Patterns

 

Hi, Eric:

The constraints feature (approved for DITA 1.2) provides a separation of concerns for extension and authoring in document design:

http://www.oasis-open.org/apps/org/workgroup/dita/download.php/25090/IssueConstraints12008.html


Does this mechanism meet the requirements for the two tiers that you are envisaging?


Hoping that's interesting?


Erik Hennum
ehennum@us.ibm.com


<Eric.Severson@flatironssolutions.com> wrote on 02/12/2008 05:53:17 PM:

> What I would like the committee to consider is:
>
> - Keeping the base topic and standard specializations loose enough to
> fit a variety of actual legacy data and internal standards, while still
> enforcing the basics of DITA
>
> - Developing tighter "best practices" specializations of these that can
> serve as a role model for good markup, and that might also be used for
> new content vs. legacy content
>
> What I think we DON'T want to do is to make the base spec so tight that
> it makes adopting DITA a matter of having to rewrite all your content
> immediately, or of being forced to accept a particular idea of "best
> practices" writing that may not match your own.
>
> This "two-tier" approach could potentially give us the best of BOTH
> worlds.



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