Inline below:
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.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.
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...
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?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”>?
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').
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: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).
- 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)
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).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 WritingAssociate Professor of Technical CommunicationDepartment of EnglishCenter for Human-Computer InteractionVirginia TechBlacksburg, 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
Founding Chair, OASIS DITA Technical Committee
LinkedIn: donrday Twitter: @donrday
About.me: Don R. Day Skype: don.r.day
Where is the knowledge we have lost in information?"
--T.S. Eliot
| Virus-free. www.avast.com |