Re: [dita-lightweight-dita] Necessity for paragraph markup in HDITA lists

[Carlos Evia <cevia@vt.edu>]

Some very good points, Don. Again, keep in mind that the existing examples had to adapt to the preliminary implementations of HDITA, MarkDITA, and XDITA built into the OT by Michael, Mark, Jarno, and me…. so they are imperfect and buggy… but they work for presentation purposes. In the original experiment (Jekyll-based), topic titles were automatically generated with liquid variables, but Jarno’s HDITA plugin did not incorporate any automation; hence the repeating title.

You are right: we could and can simplify specialized sections in HDITA. How about if something like <section data-hd-class="task/steps-informal”> becomes <section data-hd-class="steps”> and something like <section data-hd-class="topic/example”> becomes just <section data-hd-class=“example”>?

Of course, I am not opposed to experimenting with custom tags to just extend sections and keep things simple. Another potential blasphemy is to keep all Lightweight DITA flavors in just generic “topic" and then specialize sections (in XDITA or HDITA, say, a topic could have a <section-steps> if needed; no need to create a task).

I wonder if Michael and the sub-committee are ok with us (Don, Carlos, and some other geeks) playing this summer with improving our XDITA, HDITA, and MarkDITA mappings as a big step in releasing a formal SC recommendation. Since the DITA NA presentation, I have been receiving emails asking if this is “ready,” and our buggy preliminary implementations need this kind of love.

This summer I am more than happy to work on this because a) I love my Lightweight DITA and b) also because this is my main research project, and summer is the time for big research when you are faculty.

Best,

Carlos

--- 

Carlos Evia, Ph.D.

Director of Professional and Technical Writing

Associate Professor of Technical Communication

Department of English

Center for Human-Computer Interaction

Virginia Tech

Blacksburg, VA 24061-0112

(540)200-8201

On Apr 24, 2016, at 3:41 PM, Don Day <donday@donrday.com> wrote:

For discussion, a couple observations about HDITA conventions...

1. Necessity for paragraph markup in HDITA lists:

The simple HDITA samples that I've seen all have a hit-or-miss consistency for applying <li><p/></li> as a structure. Since the paragraph can be inferred for the conversion into XDITA, I question that the nested paragraph is required for the HDITA side of things. For mixed content, XSLT can sequester PCDATA into a generated paragraph during the transform into XDITA. So from an authoring perspective, I think pushing that requirement into XHTML simply creates a rule for authors that will be inconsistently applied. The MDITA case seems to bear out the same relaxation for authoring.

It can be argued that XDITA is the home for _expression_ of the architectural constraints, since that is where the standards conformant processing will actually be happening. The other formats are simply artifacts that convey authoring intent into XDITA form, with cleanup assistance from transform tools that are aware of the requirements for XDITA results. I'm all for making the authoring as simple as possible.

2. Necessity for DITA-style attribute string in data-hd-class usage:

In the Github test set, the @data patterns for example sections seem to be end-use sensitive, requiring these separate match patterns for what is essentially the same solution:
    <xsl:template match='section[@data-hd-class = "concept/example"]'>
    <xsl:template match='section[@data-hd-class = "topic/example"]'>

By contrast, the <section-example> markup would be consistent for either topics or concepts or tasks. The one downside is that the author must remember to close with the matching markup. Most markup-assisting editors will autogenerate a matching end tag, so I see this issue merely as a reminder when using totally textpad-like editors.

3. Name conflict potential if we drop the prefix part of the class notation:

I think there is no chance that disuse of the prefix could lead to domain name conflicts. The DITA 1.x family already evaluates all elements in the common namespace and therefore cannot have same-named elements in different domains. For better or worse, Lightweight DITA may need to formally eschew namespacing in order to keep the HDITA and MDITA authoring knowledge as light as possible. If you want namespaces, use Word to author and save as HTML; you'll have namespaces galore.

--

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

Virus-free. www.avast.com