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: Re: [dita-lightweight-dita] Class values in markdown and HTML


I had missed Michael's proposal to use a "dita-" prefix to disambiguate class tokens in HDITA. Given my oversight, and yesterday's discussion in the Lightweight DITA SC meeting, I withdraw my objection to using HDITA @class for this purpose.


On 4/28/19 7:44 PM, Alan Houser wrote:

Hi Michael (and LwDITA SC colleagues),

Thanks for the well-thought proposal.

I have an extremely uneasy feeling about using @class for specialization. LwDITA would be overriding an HTML5 attribute that has very common use (and usefulness), for a very particular, DITA-specific purpose.

It would also seem that all of the syntax compromises you propose would disappear if we use another attribute to support HDITA specialization.

I know the TC discussed this issue, and took a vote on the matter.

But that was nearly two years ago. I would advocate reopening the issue based on more recent experience and analysis. I hope we can at least discuss in the SC.


On 4/26/19 4:46 PM, Michael Priestley wrote:
I went back and looked at the actual limits on class values in HTML5, and they're pretty restrictive:

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:

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

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

# 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

Alan Houser
Group Wellesley, Inc.
Consultant and Trainer, Technical Publishing
arh on Twitter

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