Hey, Carlos.
I think the TC set out reasonable expectations for XDITA, and I
personally did the work (approximately 60+ hours) of
implementing the reuse. I also set up the bookmap for the LwDITA
and published the one and only PDF of the draft LwDITA spec that
was posted to Kavi last year.
Has the SC produced any new content about MDITA? Done any new
work on the LwDITA spec? When I look at the GitHub repository, I
see no work has been done since October 2019, and only sparse
work between July (when you and I last worked together) and
October 2019.
I honestly can't see what more the DITA TC can do. Robert
Anderson and I, as DITA 2.0 spec editors, set up a regular
monthly meeting with you and Alan Houser (no longer a LwDITA
spec editor). It doesn't look like many (or any?) of our
suggestions were attempted, but our suggested starting point
would be the same today: Prototype a few element-reference
topics to see how you can handle HDITA and MDITA considerations.
Developing a specification is hard work, and unfortunately
there is no way to circumvent that.
Best,
Kris
Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 622-1501; kriseberlein (skype)
On 2/6/2020 12:23 PM, Carlos Evia
wrote:
Dear DITA TC members,
The Lightweight DITA subcommittee is asking its parent
organization, the DITA technical committee, for help.
Simply put, the Lightweight DITA subcommittee does not have
the resources (mostly human) to produce a spec under the
workflow set by the TC last year. That workflow, as some TC
members probably remember, requires that every LwDITA
component reference must reuse a majority of its content from
its counterpart topic in the 2.0 spec, including attributes,
shortdesc, usage information, and rendering expectations.
While this workflow could be implemented for XDITA with
intense conditional tagging, it creates serious problems for
HDITA and particularly MDITA.
And MDITA is the main reason for the Lightweight DITA spec:
there is documented user demand for an authoritative
OASIS-approved document that specifies mappings of DITA to
Markdown. Companies and groups are already using MDITA in
production, and confusion and redundancy are in place because
there is no actual spec, and some are following Jarno's
Markdown DITA syntax reference as that authoritative resource.
Others use our committee note or even my book. Without an
OASIS-approved MDITA spec, there's no standard mapping from
DITA to Markdown and users and tool developers have to patch
implementations to accommodate many approaches for doing
DITA-like Markdown.
I hope that we can discuss this at a TC meeting and revise or
develop a strategy that allows the Lightweight DITA
subcommittee to accomplish its purpose with OASIS.
Best,
Carlos
--Â
Carlos Evia, Ph.D.
Associate Professor of
Communication
Virginia Tech
Blacksburg, VA 24061-0112
(540)200-8201
