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