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