OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita-lightweight-dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Necessity for paragraph markup in HDITA lists

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]