Re: [dita] Update/request from the LwDITA subcommittee

[Kristen James Eberlein <kris@eberleinconsulting.com>]

I think that a new committee note is well worth considering. The TC can publish a committee note much faster than a specification, and a public review is optional rather than required.

Authoring a committee note still will require some technical writing, DITA, and Git skills -- but much less than a specification. The necessary stylesheets are built and I created a template last year that serves well as a starter set for a committee note.

The subcommittee should discuss this and let the TC know if it wants to proceed with a committee note. I'll need the suggested name of the committee note in order to request the starter document from OASIS that lists the URLs and other information that is needed for the cover page.

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 2:57 PM, Michael Priestley wrote:

I think there are two issues:

1) A lack of writing resource on the LWDITA SC at the moment, especially technically focused writing (making use of conrefs etc.)
2) A tactical need for an MDITA-focused update, which doesn't need to be a formal spec but does not need to be updated since what we released in the committee note.

We haven't produced new content about MDITA, but there is work happening outside the SC, which we need to evolve and incorporate. The challenge is how and where to publish that work. If we go through the spec process for that work, there are two bottlenecks: our skilled writing resource, and the TC timeline. Alternatively, it might make sense for us to focus on producing an MDITA-focused committee note, that addresses our tactical need and bypasses (only for now, and only for this non-spec deliverable) the spec process we've set up.

Michael Priestley, Senior Technical Staff Member (STSM)
Information Architect, Digital Experience
mpriestl@ca.ibm.com



From:        Kristen James Eberlein <kris@eberleinconsulting.com>
To:        DITA TC <dita@lists.oasis-open.org>
Date:        2020/02/06 02:10 PM
Subject:        [EXTERNAL] Re: [dita] Update/request from the LwDITA subcommittee
Sent by:        <dita@lists.oasis-open.org>

---

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

--------------------------------------------------------------------- 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