Re: [dita-lightweight-dita] Fw: Lightweight DITA (IBM) and Simply DITA(Simply XML)

[Mark Giffin <mark@markgiffin.com>]

Doug Gorman says "We believe you are proposing only one level of list," but the current DTDs allow nested lists. I added a nested <ul> list to this sample topic:

https://tools.oasis-open.org/version-control/svn/dita/subcommittees/LightweightDITA/org.oasis.lwdita/samples/topic-test.dita

Also I have a question for Doug if he's listening: Do you see any need for <audio> and <video> elements in LW DITA?

Regards,
Mark Giffin
Mark Giffin Consulting, Inc.
http://markgiffin.com/


On 11/10/2015 10:23 AM, Michael Priestley wrote:

Here's feedback on our draft lightweight doctypes from Doug Gorman at SimplyXML (shared with permission)

Michael Priestley, Senior Technical Staff Member (STSM)
Enterprise Content Technology Strategist
mpriestl@ca.ibm.com
http://dita.xml.org/blog/michael-priestley
----- Forwarded by Michael Priestley/Toronto/IBM on 11/10/2015 01:22 PM -----

From:        "dgorman@simplyxml.com" <dgorman@simplyxml.com>
To:        Michael Priestley/Toronto/IBM@IBMCA
Date:        11/06/2015 03:59 PM
Subject:        FW: Lightweight DITA (IBM) and Simply DITA(Simply XML)

---

Hi Michael,
 
It was good to talk with you this week. Lightweight DITA and our Simply DITA are now very close.  We plan to modify a couple of tabs in our product, Content Mapper, and introduce our Lightweight DITA document structure soon, perhaps before the first of the year.  At this point, we are focused only on the elements and hierarchical structures in Lightweight DITA rather than any specializations or template driven business rules that Don talked about, but that seem less defined at this point.   Our caution on specializations is that we can do them, and we have done them, but our audience of non-technical writers almost never uses those features.  We think marketing people, SME’s, report writers, and other more casual authors will thrive in an environment of straight-forward Topics and Maps.
 
The Author who uses Content Mapper never sees XML and only needs to understand DITA at a very high level.  We currently have two prospects who we think are candidates for Lightweight DITA, but the Word DITA has not been prominent in the sales process because the customer is looking for control of the Word authors with ease of use, implementation of a writing standard, potential reuse, and flexible publishing.  For these situations, DITA is the means to the end rather than the end in itself.
 
From an architecture perspective, implementation of Lightweight DITA in Content Mapper is quite different than it is with an XML editor like Oxygen.  We program the elements of the schema against the Word UI to achieve the familiarity of Word with the architecture of XML.
 
We took a look at the DTD you sent a link to and we think you have addressed most of our concerns regarding the structure and content of Lightweight DITA .  Broadly, there is a requirement to be able to combine table cells.  A couple of sanitized table examples are attached (You can see that the output is styled).  
 
·         Example 1 is from a compliance company.
·         Example 2 is from a mutual (US Government) customer who uses FileNet.  It is actually a table that is about 30 pages long but I truncated it.  Based on this customer’s needs we created an integration between Content Mapper and IBM’s FileNet CMS.
 
Last year, when we were at the DITA conference in Germany we think we remember seeing a presentation of Lightweight DITA where an <image> element was inserted as a sibling of a <p> element, such a structure is no longer supported which we think is great and matches the logical hierarchy of  our current Simply DITA document structure.
 
The <fig> element however still supports both paragraph-level (<p>, <ol>, etc) elements and inline-elements (<xref>, <image> and <object>). This is inconsistent and does not align with the logical hierarchy in our Simply DITA.
 
Please note: It’s certainly possible that we are not remembering the issue correctly and what we saw at the conference was actually an <image> element inside <fig> element and not a <image> that was a sibling of <p>.
 
The actual issue related to tables is probably that those who started DITA chose to use the CALS model instead of the HTML model. The HTML model is quite simple and intuitive and we suspect it would be sufficient for close to 99% of those who use tables.
 
The DTD you sent a link to does support complex lists.
 
We will be supporting Lightweight DITA as soon as it is finalized.  It is extremely close to a subset of our Simply DITA document structure.
 
In our opinion, Lightweight DITA has great potential so we encourage you to keep it as simple as possible and let special needs and nuances be served by standard DITA.
 
Thanks for listening.
 
 
For your convenience as a refresher, here was the original thread that led to our recent meeting.

 

Hello Mike and Michael,
 
We are pleased that we are finally are seeing the use of XML and DITA emerging from TechDocs.  Because of this, we’ve been thinking about Lightweight DITA.  It will meet a strong need for casual authors and other non-technologists who don’t want to become experts in DITA or XML.
 
Once finalized, we want to support it ASAP.  As time has passed your Lightweight DITA and our Simply DITA have, to a great extent, converged.  There are currently at least three areas where we are different and I think it would be a good time to get to a common understanding.  We’ll support whatever your committee decides.   We’ve got some experience now with people who use our Simply DITA document structure and these customers probably would have been fine with Lightweight DITA, as well.  Here are the places where we seem to be divergent:
 

Area	Lightweight DITA	Simply DITA	Comment
Tables	We believe you are proposing only Simple Tables	We support complex tables.	Many of our customers want to merge cells and create complex tables for plans, if-then tables, processes, procedures, and more.
Lists	We believe you are proposing only one level of list	We support multi-level lists.	We see these all the time and strongly encourage support of multiple levels of lists.  I probably use them more often than I should, but it is the way I think about complex issues and it helps me to arrange arguments related to an issue in this way.
Structure	We believe you are proposing a structure that allows siblings of a paragraph	We do not support recursive element structures within a Topic	We can handle this as we do in other cases, for example, with paragraphs in paragraphs created with an XML Editor as valid DITA and saved in a repository.  Content Mapper uses generalize/specialize to allow opening these structures and specialized elements in Content Mapper while returning the specialized DITA to the repository.

 
With response to this, and a last look at the current schema, we’ll create a Lightweight DITA document option for Content Mapper and we might release it as a Beta if it is not finalized.  We are about to release 5.10 and our next effort will be DITA 1.3 and Lightweight DITA.
 
I would appreciate any comments you can make or questions you have, especially concerning the items in the table above.
 
Have a nice weekend.
 
Doug Gorman, CEO
 

 
There's a reason we call it Simply XML.
 
www.SimplyXML.com
P: 781.329-SXML
C: 781.801.9255
F: 800 799-2967
Skype: Douggorman