dita-lightweight-dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Fw: Lightweight DITA (IBM) and Simply DITA(Simply XML)
- From: Michael Priestley <mpriestl@ca.ibm.com>
- To: dita-lightweight-dita@lists.oasis-open.org
- Date: Tue, 10 Nov 2015 13:23:50 -0500
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
Attachment:
Table Example 2 Lightweight DITA.pdf
Description: Binary data
Attachment:
IBM Table Example 1.pdf
Description: Binary data
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]