Next in thread →
Next in month →
Re: [dita-lightweight-dita] Necessity for paragraph markup in HDITA lists
Inline below:
On 4/25/2016 8:20 AM, Carlos Evia
wrote:
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.
The demo site should let you, at least, iterate rather more quickly
than doing a build for checking student files. Students ideally need
an HDITA editor to coach them--I don't expect them to read DITA file
results to verify, and visual output is not enough to verify
adherence to best practice markup.
Frankly, once they have an HDITA editor, it is fundamentally already
a conforming XDITA forms editor that would be using the same HTML
under the covers, but saving to a different format. Same for MDITA,
come to think of it. But that's down the road...
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”>?
This is a reasonable simplification that I think has no impact to
upconversion. Ultimately the choice between custom elements and
attributes becomes one of consistency throughout the HTML5 authoring
side of things. Would you prefer authoring <span
data-hd-class="term"> or <span-term> for all inline
semantic markup?
Not to speak heresy but rather to provoke serious discussion about
the long term future of DITA-like intelligent content: Given that
custom elements inherit processing benefits on the HTML side, would
that perhaps compel us to look into this architectural mechanism on
the HTML side as a possible future base for specialization, where
XDITA becomes the alternative storage and processing
artifact? The closer we can tie JSON compatibility into the toolbox,
the more popular the uptake is likely to be (by leaps and bounds,
just sayin').
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).
This actually makes perfect sense for Web users who want to create
special function, semantic inclusions within a simpler-looking
context. This is the basis for shortcodes in the WordPress realm,
where users can add a plugin that allows them to insert new content
structures, akin to your example. Examples:
https://en.support.wordpress.com/shortcodes/ (these are
largely hooks for system-generated content)
https://wordpress.org/plugins/tabs-shortcodes/ (this example
is far more like your suggestion--this is actually introducing a
semantic structure akin to steps in a procedure)
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.
We need to move as quickly as possible on confirming the assumptions
for the architecture so that work can quickly proceed, either on a
standard DITA base (where we are now) or perhaps in parallel,
"Darwin Intelligent Content Architecture" which works out the custom
elements aspect using the Web stack--which IMO ought to be
encouraged anyway as perhaps a separate content architecture from
the XML-based publishing legacy).
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
--
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
Next in thread →
Next in month →