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
|