Got me. I was thinking of the HTML5 element <footer> when
"footnote" was mentioned. But my concern was nevertheless the
same--I wanted to make sure that "fn" and "footnote" in our
discussion both meant the same DITA thing, and not as the
placeholder <footer> of HTML5 (which can certainly hold the
result of processing a DITA fn element).
So now you have me wondering about the role of <aside> in
HDITA. Offhand I don't recall that you've mapped it as an HDITA
structure, but please remind me if you have. I think HTML5's
section and div elements are close enough surrogates for DITA's
body structures, but now I'm not sure what DITA's <fn>
should map to--maybe <aside> now that I'm refocused on your
viewpoint. I need to review my conclusions originally in this
presentation:
http://www.slideshare.net/donrday/cm-strategies-dita-north-america-2013-don-daymapping-dita-to-html5
--
Don
On 4/15/2016 7:56 PM, Michael Priestley
wrote:
Hi Don,
Going back to this email because
I had
some questions - where you thinking of the HTML5 <aside>
element
when you talked about HTML5 footnotes?
HTML5 doesn't appear to have a
footnote
element, unless it's in a side recommendation somewhere I'm not
seeing:
https://www.w3.org/TR/html5/common-idioms.html#footnotes
If we implement <fn> in
LWD, what
would we map it to in HTML5? The <aside> element is
probably easiest
to map from a structural equivalency perspective but would need
extra processing
to display as a footnote.
https://www.w3.org/TR/html5/common-idioms.html#footnotes
Michael Priestley, Senior Technical Staff Member (STSM)
Enterprise Content Technology Strategist
mpriestl@ca.ibm.com
http://dita.xml.org/blog/michael-priestley
From:
Don Day
<donday@donrday.com>
To:
dita-lightweight-dita@lists.oasis-open.org
Date:
04/01/2016 03:28 PM
Subject:
Re:
[dita-lightweight-dita]
Footnote desired in LW DITA?
Sent by:
<dita-lightweight-dita@lists.oasis-open.org>
Jan, this list IS a sounding board for ideas. Our
discussion
format is less rigorous than an RFE or RFC item, and Michael
tends to use
a consensus approach to closure on things. With that, let the
debate begin.
And after thinking at length about how HTML5's <footnote>
element
might inform on content model, I realized finally that your
question may
have been about current DITA's <fn> element, which is not
yet in
lightweight DITA. This element IS an archetype-level element
that finds
many uses in specializations. As we look to adding things back
in later
on in the LwD process, I agree that this element deserves
consideration.
When I think of a topic architecture, I look for structures that
underpin
many common instances. Is a particular item an instance, or an
archetype
or architectural feature? The archetypes and architectural
features go
into the core, the instances go into the specializations.
<fn> and <indexterm> (a bird of a feather) are
archetypes that
uniquely contain relocatable content. Generally we place
these elements
inline for context but render their content elsewhere
(contrasted with
referenceable content, content from elsewhere that gets
rendered
at the point of reference). I think they are essential in a full
implementation.
Granted, it is hard to train writers to think of content as
objects rather
than instances, but this is a case where indirection provides
great capability
for the types of queries and renditions that will drive future
content
delivery.
So if this is the case of "footnote" that you requested, then
I am fully with you. I suspect that Michael will refocus on the
adequateness
of inner content models once we finish the overall structure.
--
Don
R. Day
Founding Chair, OASIS
DITA Technical Committee
LinkedIn: donrday Twitter:
@donrday
About.me: Don
R. Day Skype:
don.r.day
"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
--T.S. Eliot
On 3/30/2016 5:01 AM, Jan Benedictus wrote:
HI all.
While migrating sample content to Lw DITA to test the new
Marketing specialization,
we ran into the limitation that there is no footnote in the
schema. I understand
that 'scope-creep' is always a risk, but still it feels that
a footnote
is a pretty versatile requirement? It wouldn t feel logical
to put this
in a specialization?
I am not sure if this is the right way to express such
findings, so my
second question is more procedure-related: what is the
correct way to communicate
such RFC's?
Cheers!
Jan
--
"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
--T.S. Eliot
|