dita-lightweight-dita — archive
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]
Some thoughts on next steps
I will not be there, but I would suggest that if there are BOF lunch
tables, this topic would be excellent to put forth so that the team
can visit informally with others and try to get some validation of
ideas in that manner.
One subtopic you might air at the table might be the name
'Lightweight DITA' and whether some other name might provide better
branding and separation from heritage associations about DITA. Also,
is there any reason you can't do EPPO and search-based collections
with Lightweight DITA (or DITA used lightly)? There were plenty of
ideas from the last meeting that could be tested against public
opinion.
Have fun. My goal during the relative quiet I expect next week is to
get the fast-wrapping-up expedita package onto Github so that it
will be available for demo implementations.
--
Don
On 4/18/2015 8:33 PM, Michael Priestley
wrote:
We had a small
meeting last time, and talked
about how to streamline our process to get something out sooner.
What do people think about
focusing
our efforts on getting the core package out ASAP, with
industry-specific
specializations being used to validate the architecture but not
necessarily
including them in the package?
For example, we could aim to
publish
a specification for V1.0 that:
- defines lightweight DITA
topics, maps,
and specialization
- defines
mappings/implementations for
XML, HTML5, markdown, JSON
- defines a lightweight
specialization
document type that allows quick generation of new map and topic
specializations
- and links to separate
pages/papers
for each industry/discipline area, which can continue being
developed after
the initial spec is published
Each domain position paper (not a
formally
approved spec) would cover:
- value proposition of lw dita
for that
domain
- listing of example roles and
scenarios
- list of example content types
- at least one example
specialization
of one of the domain-specific content types (unless none are
needed)
What do folks think? I'm
reluctant to
push too far ahead with the core spec without some validation
from the
domain analysis that we're including the right things. But maybe
we're
asking for too exhaustive an analysis. Maybe we just need enough
analysis
to ensure that we've got a useful direction, and then we can
release and
begin iterating.
Michael Priestley, Senior Technical Staff Member (STSM)
Enterprise Content Technology Strategist
[email protected]
http://dita.xml.org/blog/michael-priestley
--
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
This email has been checked for viruses by Avast antivirus software. www.avast.com
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]