|
Colleagues,
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.
-Alan
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.
https://lists.oasis-open.org/archives/dita/201903/msg00025.html
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.
-Alan
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:
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
mpriestl@ca.ibm.com
--
Alan Houser
Group Wellesley, Inc.
Consultant and Trainer, Technical Publishing
arh on Twitter
412-450-0532
|