I'm thinking the MVS (minimal viable spec)
will need:
Structure:
- maps (nesting topicrefs only - no
reltables)
- topics (title, shortdesc, sections,
blocks (paragraph, lists, table, image, audio, video))
Capabilities/attributes:
- keyref on ph for managing variable
text
- conref on blocks for higher-level
reuse (not sure if we need conkeyref)
- props on blocks for conditional processing
Maps can then be used for:
- navigation (with href on topicref)
- variable management or taxonomies
(with keys)
I think the issue with sections vs topics
can be mapped to the issue of articles vs sections in HTML5. We should
borrow their guidance and make it their problem. Otherwise, we could consider
making section abstract and only usable for specializations (where they
are essential) - but at the cost of a clear mapping to HTML5.
Re breaking compatibility with full
DITA: I'm open to the possibility, IF there is a compelling requirement.
Full processing compatibility buys us a lot in terms of tool reuse and
infrastructure integration. If we break that compatibility, it will take
a big chunk out of lightweight DITA's value proposition. It would need
to be replaced by an even bigger chunk of some new value. I don't think
this is a discussion that makes any sense in the abstract.
Is there a concrete example of where
we would want to break compatibility? If we take markdown as an example
- what could you author in markdown that wouldn't be valid in DITA?
The only examples I can think of right
now are:
- need an id for the topic
- need to start with a title
Would we be prepared to say that lightweight
DITA topics no longer need titles or ids, in order to achieve a markdown-like
level of freedom? For what it's worth I definitely want titles and ids
:-)
Michael Priestley, Senior Technical Staff Member (STSM)
Enterprise Content Technology Strategist
http://dita.xml.org/blog/michael-priestley
From:
"Noz Urbina"
<>
To:
"Fredrik Geers"
<>
Cc:
""
<>
Date:
05/07/2015 12:05 PM
Subject:
Re: [dita-lightweight-dita]
Full DITA compatibility
Sent by:
<>
Hi Fredrik,
I couldn't make the Monday meeting but a similar similar thoughts have
been coming to my mind.
My feeling is that the heart of DITA, the thing that really is needed in
all types of communication is only:
modules - delineated blocks of reusable content
shortdesc - to add progressive disclosure to modules
maps - a way to put them back together and apply contextual metadata
conref - granular reuse
(optionally, conkeyref - contextual granular reuse)
If we can bring those things over - admitting loads of people won't bother
with conkeyref - then I think we have what we need for wider use.
Semi-related thought from my own area: I'm focused on marketing/eCommerce
use cases and I'm finding that even relatively simple concepts like the
difference between topics and sections is flummoxing me. I have been
trying to do some content marketing work in DITA and doing my best to be
creative in a DITA-based system (and I'm not stranger to DITA editors).
Where I get stuck is when I make something a section and then realize it's
got to get relocated in the map or wants a short description and then I
realize I have to switch it over to topic. This is deeply disruptive to
the creative process.
I think that one of the main challenges is that lightweight DITA needs
to
"meet in the middle" with certain non-techcomm process realities.
One
example of which is that outside very disciplined areas/companies, people
just don't plan their content architectures that much. They want
reusability and modularity and portable architecture (maps) but asking
a
marketing team (for example) who has to put together 3 content pieces in
72hrs (and in the case of print will need careful visual tuning) there
are
aspects of the spec like this which seem extremely simple if you're from
a
background of more riguous or linear creation processes, but in the more
freeform environments post real challenges. I feel there has to be a
sliding-scale of complexity, even within lightweight DITA for people who
want to use it as "HTML with modules" for people who want to
have planned
architectures and proper reuse strategies and governance. I'd vote to set
the entry bar low and then lower it 5 more times...
If that means sacrificing extremely easy transition back to full DITA I
think that's acceptable losses. Although what couldn't we just put back
into a DITA generic topic? Sharing only domain specialisations (as opposed
to structural) might help?
- Noz
On Thu, May 7, 2015 5:17 pm, Fredrik Geers wrote:
> The call we had on Monday got me thinking about the DITA compatibility.
> Should it be possible to switch to the full DITA by just switching
the
> doctype?
> What is the goal of this subcommittee? To create the best possible
subset
> of DITA? Or to create something that borrows the best concepts from
DITA
> and puts it in a lightweight format? If it is the latter, it should
be
> possible for us to drop direct compatibility to allow for a simpler
> solution. I feel that if we answer this now, it would set a better
context
> for all following discussions.
>
> Also when we're talking about simplicity, we need to think about what
> makes a document model simple. What are properties that make a model
> simple? Is simplicity something with the greatest amount of freedom?
Or is
> simplicity a model that is as restrictive as possible, relieving the
> author from making certain choices? Or do we mean simplicity for
> processing the content?
>
> Markdown is an example where simplicity is accomplished through offering
> freedom. As long as you know the vocabulary, you can write your content.
> No need to worry about if one element is allowed in another element
- all
> types of content are generally allowed everywhere.
> The exact opposite of Markdown, but what still could be considered
simple,
> is a very restrictive xml schema. Because of the restrictions, it
becomes
> clear what to do, and writing documents is almost like filling in
a form.
>
> The current full DITA standard is from an authoring perspective neither
of
> above examples. It does not offer enough freedom to just "tag"
your
> content as in Markdown, though it is not restrictive enough to give
real
> clarity in how it should be used. Do we want to attempt to improve
on
> this? And can we do something about that if we're keeping the full
DITA
> compatibility?
>
> Fredrik Geers | Product Owner SDL LiveContent Create/SDL Xopus | SDL
|
> (t) +31 (0)20 201 0500 | (e)
>
>
> [http://cdn.sdl.tridion.sdlproducts.com/static/corporate/SDLlogo2014.png]
> <www.sdl.com/>
> www.sdl.com
>
>
> SDL PLC confidential, all rights reserved. If you are not the intended
> recipient of this mail SDL requests and requires that you delete it
> without acting upon or copying any of its contents, and we further
request
> that you advise us.
>
> SDL PLC is a public limited company registered in England and Wales.
> Registered number: 02675207.
> Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire
SL6
> 7DY, UK.
>
>
>
> This message has been scanned for malware by Websense. www.websense.com
>
--
Noz Urbina
Content Strategist and Founder, UrbinaConsulting.com
Author, "Content Strategy: Connecting the dots between, business,
brand,
and benefits" http://thecontentstrategybook.com
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
