OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita-lightweight-dita message

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

Subject: Re: [dita-lightweight-dita] LW DITA DTDs - adding <fig>

Here's my notes from the fig content model discussion:

<!ENTITY % all-blocks  "p|ul|ol|dl|pre|%object;|simpletable|fig">
        added fig
<!ENTITY % table-blocks  "p|ul|ol|dl|pre|%object;">
        was common-blocks - stays the same (no fig or simpletable) - ensures no nesting of simpletable directly or indirectly
<!ENTITY % fig-blocks  "p|ul|ol|dl|pre|%object;|simpletable">
        added for fig content model - allows simpletable but not nesting of figs
<!ENTITY % list-blocks "p|ul|ol|dl|pre|%object;|simpletable|fig">
        was nested-blocks - added fig

Michael Priestley, Senior Technical Staff Member (STSM)
Enterprise Content Technology Strategist

From:        Mark Giffin <mark@markgiffin.com>
To:        dita-lightweight-dita@lists.oasis-open.org
Date:        08/10/2015 11:24 AM
Subject:        Re: [dita-lightweight-dita] LW DITA DTDs - adding <fig>
Sent by:        <dita-lightweight-dita@lists.oasis-open.org>

The LW DITA DTDs are here:



On 8/10/2015 7:48 AM, Don R. Day wrote:
Web pages commonly use blockquotes for artful text quips (pull quotes, ie conrefs from the marketing/news narrative, in effect) as well as for lengthy quotes used in the usual research/context manner. Web themes usually provide a theme-specific CSS class value that manages the visual distinction. Via Lightweight DITA, authors could use an easy way to "clone elements for a new semantic role" to handle that need with improved components.

But in general, it's hard to say what ought *not* be allowed inside fig. If there is no cost to leaving them in, I'm inclined to allow more things, not less. My reasoning is that fig's payload (the part that an editor would expose as a typed field) is the same as the body field, hence an implementation could call for the same datatype handling in both editing cases. If you restrict what one field can have, then your implementation must support "fig field" content interfaces vs "body field" interfaces. In standard, schema-driven editors, these field definitions ultimately go back to PCDATA, timestamps, and other typed data primitives. Lightweight editors necessarily focus on the more narrative chunks of content, hence having fewer narrative data types helps to lower the cost of implementation. This long reasoning hearkens back to identifying what a common "para block" data-type requires and in what places that block may be allowed (body, li, lq, section, fig, note, etc. all come to mind as being basically the same).

On 8/10/2015 1:37 AM, Mark Giffin wrote:
I am adding <fig> to the Lightweight DITA DTDs and I need some agreement on what to leave out. <fig> can contain many elements and attributes in full DITA.

I think I should leave out these elements for LW DITA:

figgroup, fn, lines, lq, note, sl, data-about

I'm leaving in these elements, which were already allowed:

title, desc, data, simpletable, xref, dl, image, object, ol, p, pre, ul

Thoughts? I'm still working on the attributes.

Mark Giffin
Mark Giffin Consulting, Inc.


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:


Don R. Day
Founding Chair,
OASIS DITA Technical Committee
donrday   Twitter: @donrday
Don R. Day   Skype: don.r.day

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

This email has been checked for viruses by Avast antivirus software.

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