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