Fwd: [dita-lightweight-dita] Class values in markdown and HTML

Forwarding to the TC. This was discussed at the LwDITA
      subcommittee meeting today, and it will be on tomorrow's agenda.

    

    
Best,

      Kris

      

      Kristen James Eberlein

      Chair, OASIS DITA Technical Committee

      Principal consultant, Eberlein Consulting

      www.eberleinconsulting.com

      +1 919 622-1501; kriseberlein (skype)

      

    

    

      

      -------- Forwarded Message --------
      
        
          

            Subject:
            
            [dita-lightweight-dita] Class values in markdown and
              HTML
          

          

            Date: 
            Fri, 26 Apr 2019 16:46:53 -0400
          

          

            From: 
            Michael Priestley <>
          

          

            To: 
            
          

        
      
      

      

      I went back and looked at the
        actual limits
        on class values in HTML5, and they're pretty restrictive:

      https://www.w3schools.com/tags/att_global_class.asp

      

      To summarize:

      
        
Must begin with a letter
            A-Z or a-z

        
Can be followed by: letters
            (A-Za-z),
            digits (0-9), hyphens ("-"), and underscores ("_")

        
Multiple values separated
            by spaces

      
      

      So just copying over the XML
        syntax
        won't be valid, as I read it. It might work, in a forgiving
        browser, but
        it wouldn't be valid (slashes, +/1 signs...)

      

      So then: what's the minimum
        information
        we need to have?

      

      - the specialized element name

      - ancestor element names, if
        there's
        a possibility of multiple levels, and rules we want to fire on
        an element
        based on ancestry

      - a token to distinguish DITA
        class
        values from others

      

      So we might get something like:

      

      /start of proposal

      

      XDITA specialization:

      <prologtitle class="-
        topic/title
        mybook/prologtitle" outputclass="intro important">Header
        1</prolog-title>

      

      HDITA specialization:

      <h1 class="intro important
        dita-prologtitle">Header
        1</h1>

      

      MDITA specialization:

      # Header 1

      {: .intro .important
        .dita-prologtitle}

      

      If the prologtitle element I just
        invented
        had an intermediate ancestor (let's say chaptertitle, instead of
        being
        specialized directly from topic title), that could be expressed
        as another
        "dita-" value:

      

      XDITA: 

        <prologtitle class="- topic/title thisbook/chaptertitle
        mybook/prologtitle"
        outputclass="intro important">Header 1</prolog-title>

      

      HDITA: 

        <h1 class="intro important dita-chaptertitle
        dita-prologtitle">Header
        1</h1>

      

      MDITA: 

        # Header 1 

        {: .intro .important .dita-chaptertitle .dita-prologtitle}

      

      The sequence of the dita- values
        (ignoring
        any values that don't start with dita- ) gives us the
        specialization hierarchy
        for the element, except for the base element (topic/title),
        which we get
        from the HTML element name <h1> and the base-level
        mappings from
        <h1> to <title>.

      

      /end of proposal

      

      So what are we losing?

      

      We don't know if it's a domain or
        a
        structural specialization, but do we care? That's only really
        useful for
        full generalization rules.

      

      We're also losing the module name
        part
        of the specialization token - eg if prologtitle is specialized
        as part
        of a mybook specialization, the token in XML would be
        mybook/prologtitle.
        But I'm thinking the module name (the structural or domain
        specialization
        label) is really only useful to prevent a naming collision if
        there's two
        elements with the same name that somehow end up in the same
        document. That's
        an extreme edge case at this point, and I don't think it's worth
        adding
        complexity to the syntax in markdown and HTML5, especially since
        the /
        isn't allowed and we'd need to use a hyphen or underscore.

      

      So if people want to do full
        generalization,
        they'd need to transform the document to an XML flavour first,
        and have
        a DTD defined for it there that provided the appropriate
        specialization
        syntax in defaulted attributes, the good old fashioned DITA way.
      

      

      For simple generalization (like
        during
        a conref pulling mybook/prologtitle into thisbook/chaptertitle),
        you'd
        just compare the tokens and their sequence without the module
        names - in
        other words an HDITA, Markdown, or XDITA specialized element
        "chaptertitle"
        could pull in an HDITA or Markdown,specialized element
        "prologtitle"
        because it has "dita-chaptertitle"  as a value in its class
        attribute, and we know it's an ancestor value because it's not
        the rightmost
        "dita-"  value in the attribute.

      

        Michael Priestley, Senior Technical Staff Member (STSM)

        Product Owner, Content AI and Classification Systems, IBM
        Marketing/IBM
        Digital