|
I'd vote against renaming elements. Let's keep them the same as
in full DITA. Renaming to be "friendlier" adds an unnecessary
layer of complexity.
Best,
Kris
Kristen James Eberlein
Chair, OASIS DITA Technical Committee
Principal consultant, Eberlein Consulting
www.eberleinconsulting.com
+1 919 682-2290; kriseberlein (skype)
On 6/27/2016 10:36 AM, Michael
Priestley wrote:
Re simple-steps - I
was just making up
an example off the top of my head.
I haven't really gone back to
look at
the original specializations we did for task/concept/reference
since they're
not part of the current scope - but we do need to at some point.
The rationale for steps-informal
was
to use an element that already existed in full DITA, and was at
the section
level - that was important back in earlier iterations of
Lightweight DITA
because we had a specialization architecture built around
reusable section
specializations. But now we've gone away from that, so we've got
some flexibility/choices
to make.
So - outside the spec, we can
have a
task specialization available as an example - how do we want to
handle
steps?
- we could bring in <steps>
from
full DITA as-is - but that brings in a lot of extra elements and
baggage.
But it would be outside the spec, and if it's useful then why
not
- or we could bring in
<steps>
but simplified - we'd still need to have <cmd> in there,
but we could
ditch a bunch of the optional elements.
- or we could base off
<steps-informal>
instead, but rename it to be friendlier - like
<simple-steps> - but
it would still need to be a specialization of section, not of
<ol>
like in my example
Any thoughts?
Michael Priestley, Senior Technical Staff Member (STSM)
Enterprise Content Technology Strategist
mpriestl@ca.ibm.com
http://dita.xml.org/blog/michael-priestley
From:
Carlos Evia
<cevia@vt.edu>
To:
Michael
Priestley/Toronto/IBM@IBMCA
Cc:
dita-lightweight-dita@lists.oasis-open.org
Date:
06/26/2016 09:15 PM
Subject:
Re:
[dita-lightweight-dita]
DITA and HTML5
Sent by:
<dita-lightweight-dita@lists.oasis-open.org>
Michael (and all),
Oh but autonomous custom elements look sooo good.
I agree: customized built-in elements could work.
If anything,
they look less complicate than the original HDITA data
attributes (did
we give up on those?), which my students did not find very
difficult to
use.
We could try a complete-ish HDITA mapping in
built-in
elements and see how it looks and what creates conflict.
Your examples in this message, by the way, remind
me of
a question I was saving for the future. Whenever I show
Lightweight DITA
examples to people (MDITA, HDITA, XDITA), more than once they
have asked
about “steps-informal.” For someone who has never seen/used DITA
XML,
steps informal sounds strange because they have never seen
steps. I see
that you are using “simple-steps” here, which sounds better and
friendlier
than steps-informal.
Is this a change in our Lightweight DITA plans? If
so,
I like it…
Carlos
--
Carlos Evia, Ph.D.
Director of Professional and Technical Writing
Associate Professor of Technical Communication
Department of English
Center for Human-Computer Interaction
Virginia Tech
Blacksburg, VA 24061-0112
(540)200-8201
On Jun 26, 2016, at 8:56 PM, Michael Priestley <mpriestl@ca.ibm.com>
wrote:
I talked a bit more about it with
Don,
and this is where my thinking is right now, based on the
descriptions of
custom elements here:
https://www.w3.org/TR/custom-elements/#custom-elements-autonomous-drawbacks
- our two main alternatives are autonomous custom elements,
which we could
give custom element names to
- or customized built-in elements, which would retain the name
of an existing
HTML element plus the "is" attribute giving a custom element
name
Example for autonomous custom elements:
<simple-steps>
<simple-step>...</simple-step>
</simple-steps>
Pros:
- they have easily understandable semantic names
- they look like XML, and can more closely mimic XML
specializations
Cons:
- nothing will happen remotely resembling fallback processing
(like rendering
these as an ordered list) without a bunch of _javascript_
- for an extended discussion of how sucky this can be, see https://www.w3.org/TR/custom-elements/#custom-elements-autonomous-drawbacks
Example for customized built-in elements
<ol is="simple-steps">
<li is="simple-step">...</li>
</ol>
Pros:
- they process automatically as list items
- they can be registered using _javascript_ as special nodes, for
extra behavior,
but you only need to identify the delta stuff
Cons:
- looks less like XML
Net
My clear preference is now for customized built-in elements,
given the
warnings of the spec against using autonomous custom elements
when extending
an existing element type.
But the open question for me is whether the "is" attribute can
take multiple values. If it can, it could map really cleanly to
specializations.
Even the requirement for hyphenation in the element name could
be a mirror
for the "/" in the XML class attribute.
Otherwise we'd be looking again at limiting ourselves to one
level of specialization,
which may still be on the page anyway - nobody has said they
want it yet.
So... does anyone have a contact on the Web Platform Working
Group? I couldn't
find a simple answer to my question anywhere, including here:
https://lists.w3.org/Archives/Public/public-webapps/
If no one else has a contact I'll poke around IBM.
Michael Priestley, Senior Technical Staff Member (STSM)
Enterprise Content Technology Strategist
mpriestl@ca.ibm.com
|