dita-lightweight-dita — archive
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]
Does
Scott and Robert have both articulated valid, compelling use cases.
And I still believe support for those use cases should be limited to
full DITA.
Going further, I think the SC needs to specify clear, defining
distinctions between XDITA and full DITA, that will inform design
decisions for XDITA. Examples might be (potential blasphemy coming)
XDITA does not support specialization. Or keys. Or XYZ . A use case
distinction should really drive these decisions, but the use case
distinction must be something more clear and compelling than XDITA
is a solution for organizations that need DITA but want fewer
element types .
One source of my struggle with this issue ... it's really not very
complicated to author in DITA <topic> with only the
highlighting domain integrated. And that's what XDITA is starting to
look like.
-Alan
On 3/31/17 10:57 AM, Scott Hudson
wrote:
Additionally,
we heard from several folks in the DITA listening sessions
that they want the ability to associate common metadata with
topics. Wouldn’t the @href allow that opportunity to link
out to external metadata? If so, I think it should remain in
both LW and full DITA.
Thanks
and best regards,
--Scott
Scott
Hudson
Content Strategist
Digital
Aviation Learning & Development
Jeppesen
Digital Aviation
Boeing
55
Inverness Drive East
Englewood,
CO 80112
www.jeppesen.com
This
document contains only administrative, uncontrolled data
under U.S. International Traffic in Arms Regulations.
From:
<[email protected]>
on behalf of Robert D Anderson <[email protected]>
Date: Friday, March 31, 2017 at 8:53 AM
To: Carlos Evia <[email protected]>
Cc:
[email protected]
<[email protected]> ,
[email protected]
<[email protected]>
Subject: Re: [dita-lightweight-dita] Does
<data> need @href?
(Let's
begin with my usual caveat about my years of focus on full
DITA rather than lightweight, and then...)
The href attribute is pretty
commonly used on <data> elements, with fairly
straightforward use cases -- it either tells where the piece
of metadata came from, or where to go to find more of it.
For example, I regularly seem
to write sample topics about puffins. Anything based on a
surprising fact from our favorite fact source might be
tagged:
<data name= source
value= wikipedia href= true href= https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Puffin&d=DwMGaQ&c=P3aKjizb3qsxp0SERaL2sw&r=YQWdLfM9mekBOdoMmoBdn9RgyqIHrveGolBbb4_uGWQ&m=_gxDTqDuIfgVP3SrcyvNfG75vdB8BhCXroxjCuw2G8o&s=t8AE1EtSkwWE3xSeLfMT3PM824jsb7kkYlvIz0iQuQA&e=
> https://en.wikipedia.org/wiki/Puffin
/>
For the few not writing about
puffins, href really is the more semantic choice if you're
trying to reference anything outside of the topic:
<prolog>
<data name= changelog
href= true
href= http://example.com/changes-to-this-topic.log
>http://example.com/changes-to-this-topic.log />
<data
name= previous-version href= true
href= http://example.com/versionX.log
> http://example.com/versionX.log
/>
<data name= from-collection
href=
class= moz-txt-link-rfc2396E href= http://example.com/collection/
> http://example.com/collection/ />
</prolog>
Obviously with that sample,
those are pairs, so you could use name + value. But if you
were doing it in full DITA, and used @value for a reference
like that, I think a lot of people would be shaking their
heads and wondering why.
Anyway, if you're already going
to have <data> available already this seems to be a
pretty common use case for both full and LwDITA.
Regards,
Robert
D. Anderson
DITA-OT
lead and
Co-editor
DITA
1.3 specification
,
Digital Services Group
E-mail:
[email protected]
Digital
Services Group
11501
BURNET RD,, TX, 78758-3400, AUSTIN, USA
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]