Lightweight DITA SC

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. http://markgiffin.com/

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). -- Don 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. http://markgiffin.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 -- Don R. Day Founding Chair, OASIS DITA Technical Committee LinkedIn: donrday    Twitter: @donrday About.me: 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. www.avast.com

The LW DITA DTDs are here: https://tools.oasis-open.org/version-control/svn/dita/subcommittees/LightweightDITA/org.oasis.lwdita Mark 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). -- Don 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. http://markgiffin.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 -- Don R. Day Founding Chair, OASIS DITA Technical Committee LinkedIn: donrday    Twitter: @donrday About.me: 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. www.avast.com

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 mpriestl@ca.ibm.com http://dita.xml.org/blog/michael-priestley 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: https://tools.oasis-open.org/version-control/svn/dita/subcommittees/LightweightDITA/org.oasis.lwdita Mark 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). -- Don 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. http://markgiffin.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 -- Don R. Day Founding Chair, OASIS DITA Technical Committee LinkedIn: donrday    Twitter: @donrday About.me: 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. www.avast.com

I tested the case of paragraph behaviors in list items. According to this attached test case, default browser CSS (yes, there is such a thing) already gracefully handles the case of a first paragraph within a list item. Bring this up in any browser, and the both list items should display fine with normal "content to content" spacing, not "markup to markup" which was what I was afraid the OT was doing. OT is doing no wrong that I can see. And I back off from the assertion that p[1] should be output as <div>... this only makes sense if a semantically neutral content type is needed for some other reason. Still, this shows that the theming content will normally take care of list compaction. Without the style, both contexts render as "open," but authors should not have to author as if they knew where that list was going to end up. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus Normal paragraph in body context. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum tincidunt est vitae ultrices accumsan. Aliquam ornare lacus adipiscing, posuere lectus et, fringilla augue. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum tincidunt est vitae ultrices accumsan. Aliquam ornare lacus adipiscing, posuere lectus et, fringilla augue. List in a normally open context (eg, body of web page) Normal paragraph in list item context. The containing list item should manage its own visual separation from whatever is before. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum tincidunt est vitae ultrices accumsan. Aliquam ornare lacus adipiscing, posuere lectus et, fringilla augue. Subsequent list item. Subsequent list item. Normal mixed content in list item context--there is no paragraph wrapper for this text. The containing list item should manage its own visual separation from whatever is before. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum tincidunt est vitae ultrices accumsan. Aliquam ornare lacus adipiscing, posuere lectus et, fringilla augue. Subsequent list item. Subsequent list item. List in a normally closed up context (eg, sidebar of web page) Normal paragraph in list item context. The containing list item should manage its own visual separation from whatever is before. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum tincidunt est vitae ultrices accumsan. Aliquam ornare lacus adipiscing, posuere lectus et, fringilla augue. Subsequent list item. Subsequent list item. Normal mixed content in list item context--there is no paragraph wrapper for this text. The containing list item should manage its own visual separation from whatever is before. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum tincidunt est vitae ultrices accumsan. Aliquam ornare lacus adipiscing, posuere lectus et, fringilla augue. Subsequent list item. Subsequent list item. List back in the body context Normal paragraph in list item context. The containing list item should manage its own visual separation from whatever is before. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum tincidunt est vitae ultrices accumsan. Aliquam ornare lacus adipiscing, posuere lectus et, fringilla augue. Subsequent list item. Subsequent list item. Normal mixed content in list item context--there is no paragraph wrapper for this text. The containing list item should manage its own visual separation from whatever is before. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum tincidunt est vitae ultrices accumsan. Aliquam ornare lacus adipiscing, posuere lectus et, fringilla augue. Subsequent list item. Subsequent list item. Normal paragraph in body context. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum tincidunt est vitae ultrices accumsan. Aliquam ornare lacus adipiscing, posuere lectus et, fringilla augue. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum tincidunt est vitae ultrices accumsan. Aliquam ornare lacus adipiscing, posuere lectus et, fringilla augue.

Let's try this again with the correct text inside the subsequent paragraphs in a new attachment--disregard the previous one. On 8/10/2015 11:32 AM, Don R. Day wrote: I tested the case of paragraph behaviors in list items. According to this attached test case, default browser CSS (yes, there is such a thing) already gracefully handles the case of a first paragraph within a list item. Bring this up in any browser, and the both list items should display fine with normal content to content spacing, not markup to markup which was what I was afraid the OT was doing.  OT is doing no wrong that I can see. And I back off from the assertion that p[1] should be output as <div>... this only makes sense if a semantically neutral content type is needed for some other reason. Still, this shows that the theming content will normally take care of list compaction. Without the style, both contexts render as open, but authors should not have to author as if they knew where that list was going to end up. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus --------------------------------------------------------------------- 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 -- Don R. Day Founding Chair, OASIS DITA Technical Committee LinkedIn: donrday    Twitter: @donrday About.me: 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. www.avast.com Normal paragraph in body context. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum tincidunt est vitae ultrices accumsan. Aliquam ornare lacus adipiscing, posuere lectus et, fringilla augue. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum tincidunt est vitae ultrices accumsan. Aliquam ornare lacus adipiscing, posuere lectus et, fringilla augue. List in a normally open context (eg, body of web page) Normal paragraph in list item context. Normal paragraph in list item context. The containing list item should manage its own visual separation from whatever is before. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum tincidunt est vitae ultrices accumsan. Aliquam ornare lacus adipiscing, posuere lectus et, fringilla augue. Subsequent para. Subsequent para. Normal mixed content in list item context--there is no paragraph wrapper for this text. The containing list item should manage its own visual separation from whatever is before. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum tincidunt est vitae ultrices accumsan. Aliquam ornare lacus adipiscing, posuere lectus et, fringilla augue. Subsequent para. Subsequent para. List in a normally closed up context (eg, sidebar of web page) Normal paragraph in list item context. Normal paragraph in list item context. The containing list item should manage its own visual separation from whatever is before. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum tincidunt est vitae ultrices accumsan. Aliquam ornare lacus adipiscing, posuere lectus et, fringilla augue. Subsequent para. Subsequent para. Normal mixed content in list item context--there is no paragraph wrapper for this text. The containing list item should manage its own visual separation from whatever is before. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum tincidunt est vitae ultrices accumsan. Aliquam ornare lacus adipiscing, posuere lectus et, fringilla augue. Subsequent para. Subsequent para. List back in the body context Normal paragraph in list item context. The containing list item should manage its own visual separation from whatever is before. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum tincidunt est vitae ultrices accumsan. Aliquam ornare lacus adipiscing, posuere lectus et, fringilla augue. Subsequent para. Subsequent para. Normal mixed content in list item context--there is no paragraph wrapper for this text. The containing list item should manage its own visual separation from whatever is before. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum tincidunt est vitae ultrices accumsan. Aliquam ornare lacus adipiscing, posuere lectus et, fringilla augue. Subsequent para. Subsequent para. Normal paragraph in body context. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum tincidunt est vitae ultrices accumsan. Aliquam ornare lacus adipiscing, posuere lectus et, fringilla augue. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum tincidunt est vitae ultrices accumsan. Aliquam ornare lacus adipiscing, posuere lectus et, fringilla augue.

Hi Mark,   I have looked at the DTD’s stored in the link you send (revision 3041). But I cannot see that fig is add. Are this really the most recent DTD’s?   Kind regards, Birgit   Van: dita-lightweight-dita@lists.oasis-open.org [mailto:dita-lightweight-dita@lists.oasis-open.org] Namens Mark Giffin Verzonden: maandag 10 augustus 2015 17:23 Aan: dita-lightweight-dita@lists.oasis-open.org Onderwerp: Re: [dita-lightweight-dita] LW DITA DTDs - adding <fig>   The LW DITA DTDs are here: https://tools.oasis-open.org/version-control/svn/dita/subcommittees/LightweightDITA/org.oasis.lwdita Mark

Hi Birgit, Yes those are the latest DTDs, I have added <fig> yet. I am really going to try to get fig added before our next LW DITA SC meeting in a couple of days. Regards, Mark Giffin Mark Giffin Consulting, Inc. http://markgiffin.com/ On 9/2/2015 1:30 AM, birgit wrote: Hi Mark,   I have looked at the DTD’s stored in the link you send (revision 3041). But I cannot see that fig is add. Are this really the most recent DTD’s?   Kind regards, Birgit   Van: dita-lightweight-dita@lists.oasis-open.org [ mailto:dita-lightweight-dita@lists.oasis-open.org ] Namens Mark Giffin Verzonden: maandag 10 augustus 2015 17:23 Aan: dita-lightweight-dita@lists.oasis-open.org Onderwerp: Re: [dita-lightweight-dita] LW DITA DTDs - adding <fig>   The LW DITA DTDs are here: https://tools.oasis-open.org/version-control/svn/dita/subcommittees/LightweightDITA/org.oasis.lwdita Mark

I meant to say that I have NOT added <fig> yet. Mark On 9/4/2015 3:10 PM, Mark Giffin wrote: Hi Birgit, Yes those are the latest DTDs, I have added <fig> yet. I am really going to try to get fig added before our next LW DITA SC meeting in a couple of days. Regards, Mark Giffin Mark Giffin Consulting, Inc. http://markgiffin.com/ On 9/2/2015 1:30 AM, birgit wrote: Hi Mark,   I have looked at the DTD’s stored in the link you send (revision 3041). But I cannot see that fig is add. Are this really the most recent DTD’s?   Kind regards, Birgit   Van: dita-lightweight-dita@lists.oasis-open.org [ mailto:dita-lightweight-dita@lists.oasis-open.org ] Namens Mark Giffin Verzonden: maandag 10 augustus 2015 17:23 Aan: dita-lightweight-dita@lists.oasis-open.org Onderwerp: Re: [dita-lightweight-dita] LW DITA DTDs - adding <fig>   The LW DITA DTDs are here: https://tools.oasis-open.org/version-control/svn/dita/subcommittees/LightweightDITA/org.oasis.lwdita Mark

For what it is worth, for all clients for whom I've implemented constraints, everyone ONLY wanted fig to contain image, object, title, data, and and desc. I can see a use case for <pre> and <simpletable>, but what would use cases for xref, dl, pl, ul, or p be? Best, Kris Kristen James Eberlein Chair, OASIS DITA Technical Committee Principal consultant, Eberlein Consulting www.eberleinconsulting.com +1 919 682-2290; kriseberlein (skype) On 8/10/2015 2: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. http://markgiffin.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

Hi there, I've had folks want to use definition lists, ordered lists, and unordered lists for legends, but never had a use case for cross references or paragraphs. If we could make a recommendation for supporting figure legends, then maybe we could limit the available elements. Amber
Original Message----- From: dita-lightweight-dita@lists.oasis-open.org [ mailto:dita-lightweight-dita@lists.oasis-open.org ] On Behalf Of Kristen James Eberlein Sent: Monday, August 10, 2015 10:01 AM To: dita-lightweight-dita@lists.oasis-open.org Subject: Re: [dita-lightweight-dita] LW DITA DTDs - adding <fig> For what it is worth, for all clients for whom I've implemented constraints, everyone ONLY wanted fig to contain image, object, title, data, and and desc. I can see a use case for <pre> and <simpletable>, but what would use cases for xref, dl, pl, ul, or p be? Best, Kris Kristen James Eberlein Chair, OASIS DITA Technical Committee Principal consultant, Eberlein Consulting www.eberleinconsulting.com +1 919 682-2290; kriseberlein (skype) On 8/10/2015 2: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. > http://markgiffin.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 > > --------------------------------------------------------------------- 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

In the discussion today, one of the goals was to limit the number of different editing contexts - effectively, the number of different rules about what's allowed where. We tried to balance these considerations:  - want to limit choices to help usability  - but want to increase consistency to help usability We tried to keep the content model for fig as close as possible to the content model for section - only eliminating fig itself because that would have broken the mapping to full DITA. So the content model we arrived at was: <!ENTITY % fig-blocks  "p ul ol dl pre %object; simpletable"> Michael Priestley, Senior Technical Staff Member (STSM) Enterprise Content Technology Strategist mpriestl@ca.ibm.com http://dita.xml.org/blog/michael-priestley From:         Amber Swope <amber@ditastrategies.com> To:         Kristen James Eberlein <kris@eberleinconsulting.com>, dita-lightweight-dita@lists.oasis-open.org Date:         08/10/2015 01:05 PM Subject:         RE: [dita-lightweight-dita] LW DITA DTDs - adding <fig> Sent by:         <dita-lightweight-dita@lists.oasis-open.org> Hi there, I've had folks want to use definition lists, ordered lists, and unordered lists for legends, but never had a use case for cross references or paragraphs. If we could make a recommendation for supporting figure legends, then maybe we could limit the available elements. Amber
Original Message----- From: dita-lightweight-dita@lists.oasis-open.org [ mailto:dita-lightweight-dita@lists.oasis-open.org ] On Behalf Of Kristen James Eberlein Sent: Monday, August 10, 2015 10:01 AM To: dita-lightweight-dita@lists.oasis-open.org Subject: Re: [dita-lightweight-dita] LW DITA DTDs - adding <fig> For what it is worth, for all clients for whom I've implemented constraints, everyone ONLY wanted fig to contain image, object, title, data, and and desc. I can see a use case for <pre> and <simpletable>, but what would use cases for xref, dl, pl, ul, or p be? Best, Kris Kristen James Eberlein Chair, OASIS DITA Technical Committee Principal consultant, Eberlein Consulting www.eberleinconsulting.com +1 919 682-2290; kriseberlein (skype) On 8/10/2015 2: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. > http://markgiffin.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 > > --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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